Vehicle and authentication method, system, and storage medium

Abstract

Embodiments of the present application provide a vehicle, an authentication method, a system and a storage medium. The method is applied to a vehicle controller of a vehicle and includes the following steps: sending an authentication request to a to-be-authenticated module and receiving an encrypted message returned by the to-be-authenticated module; performing authentication on the encrypted message based on verification information, a first vehicle identification code stored by the vehicle controller and a key to obtain an authentication result, wherein the verification information is generated by the vehicle controller in response to a start instruction of the vehicle, and the authentication result is used to represent whether the to-be-authenticated module passes the authentication; and returning the authentication result to the to-be-authenticated module. The present application solves the technical problem of poor safety of the vehicle.

Description

Technical Field

[0001] This application relates to the fields of vehicles and authentication, and more specifically, to a vehicle and authentication method, system and storage medium. Background Technology

[0002] In an era where the vehicle industry is rapidly transforming towards electrification, intelligence, and connectivity, vehicles have evolved from simple means of transportation into mobile intelligent terminals integrating complex software and hardware. Vehicle safety and reliability are therefore of paramount importance.

[0003] Currently, pre-stored static verification codes are often used to authenticate the various modules in a vehicle. However, static verification codes are easily cracked, resulting in poor vehicle security.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] This application provides a vehicle, authentication method, system, and storage medium to at least address the technical problem of poor vehicle security.

[0006] According to one aspect of the embodiments of this application, a vehicle authentication method is provided, applied to a vehicle controller, comprising: sending an authentication request to a module to be authenticated and receiving an encrypted message returned by the module to be authenticated; authenticating the encrypted message based on verification information, a first vehicle identification code stored in the vehicle controller, and a key to obtain an authentication result, wherein the verification information is generated by the vehicle controller in response to a vehicle start command, and the authentication result is used to characterize whether the module to be authenticated has passed authentication; and returning the authentication result to the module to be authenticated.

[0007] Optionally, before receiving the encrypted message returned by the module to be authenticated, the above method further includes: establishing a connection with the electronic inspection device; sending the first vehicle identification code to the electronic inspection device; and receiving the key returned by the electronic inspection device, wherein the key is received from the cloud after the electronic inspection device sends the first vehicle identification code to the cloud, and the first vehicle identification code and the key are associated and stored in the cloud.

[0008] Optionally, before receiving the encrypted message returned by the module to be authenticated, the method further includes: establishing a connection with a diagnostic device, wherein the diagnostic device and the electrical testing device are devices at different nodes in the production line; receiving a registration request sent by the diagnostic device, wherein the registration request is generated based on the private key of the diagnostic device; verifying the diagnostic device based on the registration request and the public key corresponding to the diagnostic device, and obtaining a verification result, wherein the public key is pre-programmed into the hardware security area in the vehicle controller, and the verification result is used to characterize whether the vehicle controller has passed the verification; if the verification result indicates that the vehicle controller has passed the verification, receiving and storing the first vehicle identification code sent by the diagnostic device.

[0009] Optionally, based on verification information, the first vehicle identification code stored in the vehicle controller, and a key, the encrypted message is authenticated to obtain an authentication result, including: decrypting the encrypted message based on the key and verification information to obtain a second vehicle identification code; and obtaining an authentication result based on the second vehicle identification code and the first vehicle identification code. Preferably, obtaining an authentication result based on the second vehicle identification code and the first vehicle identification code includes: if the second vehicle identification code and the first vehicle identification code are consistent, determining that the authentication result indicates that the module to be authenticated has passed authentication; if the second vehicle identification code and the first vehicle identification code are inconsistent, determining that the authentication result indicates that the module to be authenticated has failed authentication.

[0010] Optionally, after authenticating the encrypted message based on the verification information, the first vehicle identification code and key stored in the vehicle controller, and obtaining the authentication result, the above method further includes: disconnecting the connection with the module to be authenticated and generating a security message if the authentication result indicates that the module to be authenticated has failed authentication; and sending the security message to the display device.

[0011] According to another aspect of the embodiments of this application, a vehicle authentication method is also provided, applied to a module to be authenticated in a vehicle, comprising: receiving an authentication request sent by a vehicle controller and obtaining verification information from the authentication request; generating an encrypted message based on the verification information, a first vehicle identification code and a key stored in the module to be authenticated, wherein the vehicle controller is deployed in the vehicle, and the encrypted message is used to authenticate the module to be authenticated through the vehicle controller; sending the encrypted message to the vehicle controller and receiving an authentication result returned by the vehicle controller, wherein the authentication result is used to characterize whether the module to be authenticated has passed authentication.

[0012] According to another aspect of the embodiments of this application, a vehicle authentication system is also provided, comprising: a module to be authenticated, deployed in the vehicle, the module to be authenticated being used to receive an authentication request sent by a vehicle controller, obtain verification information from the authentication request, generate an encrypted message based on the verification information, a first vehicle identification code and a key stored in the module to be authenticated, send the encrypted message to the vehicle controller, and receive an authentication result returned by the vehicle controller, wherein the encrypted message is used to authenticate the module to be authenticated by the vehicle controller, and the authentication result is used to characterize whether the module to be authenticated has passed authentication; and a vehicle controller, deployed in the vehicle, the vehicle controller being used to send an authentication request to the module to be authenticated, receive the encrypted message returned by the module to be authenticated, authenticate the encrypted message based on the verification information, the first vehicle identification code and the key stored in the vehicle controller, obtain an authentication result, and return the authentication result to the module to be authenticated, wherein the verification information is generated by the vehicle controller in response to a vehicle start command.

[0013] Optionally, the system further includes: a diagnostic device, used to generate a registration request based on the private key stored in the diagnostic device after establishing a connection with the vehicle controller, and send the registration request to the vehicle controller, receive the verification result returned by the vehicle controller, and write the first vehicle identification code into the module to be authenticated and the vehicle controller if the verification result indicates that the vehicle controller has passed the verification; preferably, the system further includes: an electronic testing device, used to read the first vehicle identification code after establishing a connection with the vehicle controller, generate a key request based on the first vehicle identification code, send the key request to the cloud, receive the key returned by the cloud, and inject the key into the module to be authenticated and the vehicle controller.

[0014] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0019] In this embodiment, the vehicle controller sends an authentication request to the module to be authenticated and receives an encrypted message returned by the module. Based on the verification information, the first vehicle identification code, and the key stored in the vehicle controller, the encrypted message is authenticated to obtain an authentication result. The verification information is generated by the vehicle controller in response to the vehicle's start command, and the authentication result indicates whether the module to be authenticated has passed authentication. The authentication result is then returned to the module to be authenticated. This method involves the vehicle controller actively initiating an authentication request to obtain the encrypted message returned by the module to be authenticated. It then uses the verification information generated during vehicle startup, along with the first vehicle identification code and the key, to authenticate the encrypted message. Because the verification information is dynamically generated, the encrypted message is difficult to replay, ensuring the authenticity of the authentication result and achieving the goal of ensuring vehicle security. This improves vehicle security and solves the technical problem of poor vehicle security. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a flowchart of a vehicle authentication method according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of a vehicle authentication method according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of a vehicle authentication system according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of an optional full-process vehicle authentication method according to an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of an optional vehicle production stage certification method according to an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of an optional vehicle off-line certification method according to an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of an optional vehicle operation phase authentication method according to an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of a vehicle authentication device according to an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of a vehicle authentication device according to an embodiment of this application;

[0030] Figure 10 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] According to an embodiment of this application, a method embodiment for authenticating a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This embodiment provides a vehicle authentication method applied to a vehicle controller. Figure 1 This is a flowchart of a vehicle authentication method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0035] Step S102: Send an authentication request to the module to be authenticated and receive the encrypted message returned by the module to be authenticated.

[0036] The aforementioned vehicle is not merely a means of transportation with a power system, but also an intelligent mobile terminal integrating a complex electronic architecture, communication capabilities, security mechanisms, and a user interface. In this embodiment, the vehicle is a dynamic security node with identity identification, trusted authentication capabilities, and proactive defense mechanisms, providing the implementation environment and boundary conditions for the entire tamper-proof authentication system. The authentication process in this embodiment is completed within the vehicle's hardware platform and electrical architecture.

[0037] The uniqueness of a vehicle is defined by its Vehicle Identification Number (VIN), which serves as its identity anchor throughout its entire lifecycle, from manufacturing and registration to use and scrapping. In this embodiment, the vehicle's startup triggers the authentication process, meaning the vehicle itself becomes the source and endpoint of the authentication logic. The vehicle's electronic and electrical architecture supports Controller Area Network (CAN) bus communication, providing a physical channel for the transmission of authentication requests and encrypted messages. Its power management system ensures that the authentication process is reliably activated at ignition, while its secure storage area provides hardware-level protection for the key and VIN, making them difficult for ordinary software to access. The vehicle's structural design dictates that the authentication process is embedded in the critical control unit, preventing external placement or bypassing, thus ensuring the intrinsic nature and unavoidability of the authentication process.

[0038] This means that vehicles can self-verify the authenticity of modules to be authenticated, such as communication modules, becoming intelligent entities capable of proactively determining the trustworthiness of external components. This is crucial for preventing new types of attacks such as remote hijacking and other software upgrades. Vehicle security no longer relies on external firewalls or cloud encryption, but is internalized within its own authentication mechanism. This is the core manifestation of the zero-trust architecture in the automotive field.

[0039] The aforementioned vehicle controller is the core execution unit and security arbitrator, serving as the vehicle's security hub, endowed with authentication, key management, and security decision-making capabilities. In the vehicle's electronic architecture, the vehicle controller typically functions as a domain controller or master control unit, possessing processing power, multi-bus communication interfaces, and hardware security modules. The vehicle controller's functions extend beyond signal acquisition and control execution; it is the decision-maker that proactively initiates authentication requests, compares keys, decrypts messages, determines legitimacy, and executes security isolation policies. The primary vehicle identification number (VIN) and key stored in the vehicle controller can be permanently embedded in a hardware security area, making them difficult to read or tamper with using conventional software methods.

[0040] The vehicle controller can automatically trigger the authentication process each time the vehicle starts, sending a challenge message to the module to be authenticated via the bus and waiting for a returned encrypted message. This behavior demonstrates its proactive and real-time nature. The vehicle controller not only verifies the identity of external modules but also achieves two-way identity confirmation, ensuring that the module has not been replaced. If authentication fails, the vehicle controller has the ability to immediately disconnect the communication link to prevent potential malicious commands from infiltrating the vehicle's critical systems through tampered modules. Simultaneously, it generates a security message and notifies the display device, achieving a closed-loop response. This transforms the vehicle controller from a passive control node into a system-level proactive defense node.

[0041] As a trust anchor point within the vehicle, the vehicle controller unifies and integrates the authentication processes that were originally scattered across different modules, forming a traceable, auditable, and executable global security policy. This lays the architectural foundation for subsequent mutual authentication of authentication modules such as gateways, autonomous driving domains, and smart cockpits, thereby contributing to the construction of an intrinsic vehicle security system.

[0042] The aforementioned module to be certified is the core object to be verified. It can be an in-vehicle information and communication module, which integrates functions such as cellular communication, positioning, remote diagnostics and software upgrades. It is the exit point for the vehicle to establish a connection with the external network.

[0043] The module to be authenticated is a trusted terminal with secure storage and cryptographic operation capabilities. The security of the module to be authenticated is directly related to the trustworthiness of the entire vehicle communication link. During the vehicle production stage, the module to be authenticated is pre-programmed with a unique vehicle identification code and a dynamically generated key. This information is securely written into its internal hardware security area, isolated from ordinary application data, and cannot be read or tampered with by external software.

[0044] Upon receiving an authentication request from the vehicle controller, the module to be authenticated uses the key and verification information to perform encryption operations, generating a unique encrypted message to prove the authenticity and integrity of its identity. The module to be authenticated does not initiate communication but responds to authentication requests, thereby enhancing system security. The module to be authenticated not only provides communication services but also acts as the physical carrier of the vehicle's trusted identity, ensuring traceability of interactions between the vehicle and the cloud, infrastructure, and other vehicles. If the module to be authenticated is replaced or its firmware is tampered with, it will be unable to generate the correct encrypted message and will be isolated by the vehicle controller. This mechanism prevents unauthenticated modules from accessing the vehicle network system.

[0045] The aforementioned authentication request is the initial signal for the vehicle controller to initiate the authentication process, serving as a security-intended authentication trigger mechanism. The authentication request can be proactively sent by the vehicle controller upon vehicle startup. It may contain verification information, such as through a protocol frame header or a specific function code, to establish a secure communication starting point. The sending condition of the authentication request is limited to the vehicle startup event, ensuring that authentication is triggered under legitimate usage scenarios and avoiding meaningless continuous polling or forged requests induced by attackers. The transmission path of the authentication request typically traverses the vehicle's highly reliable controller area network bus, with the receiver being a specific module to be authenticated. This targeted transmission mechanism prevents erroneous responses from non-target modules.

[0046] The authentication request transforms the authentication process from "passive verification" to "active checking," freeing vehicles from relying on pre-set static trust. Instead, it continuously verifies whether the vehicle remains in its original trusted state through dynamic queries at each startup. This mechanism effectively defends against attacks that allow normal communication even after the module to be authenticated has been replaced, because attackers cannot predict the generation time and content of the authentication request, nor can they forge a compliant response without a key.

[0047] In one optional embodiment, the vehicle controller sends an authentication request to the module to be authenticated, indicating that the system is about to verify the module. The authentication request is the initial trust starting point for establishing bidirectional communication, ensuring that subsequent data exchanges occur in a controlled, intentional interactive environment, rather than in disordered or hijacked communication channels. The authentication request breaks with the traditional security mindset of defaulting module trust, making each startup an opportunity for identity authentication and preventing other modules from automatically connecting and executing commands after the vehicle is powered on.

[0048] After issuing an authentication request, the vehicle controller waits for and captures the encrypted response message. It can monitor the vehicle's bus to obtain credentials proving the authenticity and software integrity of the module to be authenticated, ensuring that the response cannot be forged or copied by a third party. This provides the raw input for subsequent decryption and comparison. The encrypted message is the system's only verifiable evidence. It transforms abstract identity trust into a computable and verifiable mathematical expression, making the authentication process resistant to attacks. Even if an attacker intercepts the communication, it is difficult to generate new valid messages, ensuring that only modules with the correct key can pass verification, thus building an inherent security defense system within the vehicle.

[0049] Step S104: Based on the verification information, the first vehicle identification code and key stored in the vehicle controller, the encrypted message is authenticated to obtain the authentication result.

[0050] The verification information is generated by the vehicle controller in response to the vehicle's start command, and the authentication result is used to characterize whether the module to be authenticated has passed the authentication.

[0051] The aforementioned verification information consists of dynamic parameters generated by the vehicle controller during each authentication process. These parameters are crucial for ensuring the uniqueness of the authentication session and preventing replay attacks. The verification information is neither a fixed value nor a static identifier; rather, it is a temporary challenge value generated at each startup and valid only for the current authentication. The generation of verification information is triggered by the vehicle startup command and can be generated by the vehicle controller's internal security hardware modules or encryption algorithms.

[0052] Verification information can be a random number, an incrementing counter value, a timestamp, or a unique sequence based on hardware entropy. Its function is to serve as an input parameter for generating encrypted messages, mixing it with the key and vehicle identification number (VIN) of the module to be authenticated to ensure the immediacy of the output encrypted message. Verification information prevents attackers from using a single successfully authenticated message for long-term impersonation. As a computational factor, verification information will not reveal the key or VIN even if eavesdropped on, providing strong information security. The VIN transforms authentication from a "static comparison" to a "dynamic interaction," preventing attackers from deceiving the system by pre-recording legitimate messages. The VIN serves as a dynamic link between the vehicle controller's trust starting point and the module's response endpoint. The introduction of the VIN enables the authentication system to resist replay attacks, facilitating proactive protection mechanisms.

[0053] The aforementioned first vehicle identification number is a unique identifier for a vehicle worldwide. It can consist of 17 characters and is assigned by the vehicle manufacturer during production. It has global uniqueness and binding force.

[0054] The First Vehicle Identification Number (PVI) serves as the trust anchor of the entire authentication system, connecting the physical vehicle, cloud data, and onboard modules. PVIs can be generated by national vehicle management agencies or manufacturer coding systems to reflect information such as country of origin, manufacturer, model, year, and serial number. It is the core identity credential for a vehicle throughout its entire lifecycle, including registration, maintenance, recalls, and insurance.

[0055] Before a vehicle rolls off the production line, the First Vehicle Identification Code (PVIC) can be written into the hardware secure storage area of ​​the vehicle controller and the module to be authenticated via a secure channel by diagnostic equipment. This PVIC is difficult to modify or erase using conventional software methods. The PVIC not only identifies the vehicle but also serves as a unique index binding a dynamically generated key in the cloud to the real vehicle. This ensures that each vehicle's key corresponds one-to-one with a specific PVIC, preventing the possibility of module misuse across vehicles. It aligns the vehicle's digital identity with its physical identity, achieving security goals such as "one vehicle, one key," "lifetime binding," and "anti-porting." In a connected vehicle environment, the PVIC serves as the basis for the cloud platform to verify vehicle legitimacy, authorize software upgrades, and track the access of other devices.

[0056] The aforementioned key is the element for identity authentication and data encryption, serving as a trust password connecting the cloud, electrical testing equipment, diagnostic equipment, and the vehicle controller. The key can be a high-strength symmetric encryption key dynamically generated by the cloud for each vehicle, possessing uniqueness and randomness. The key can be a 128-bit or 256-bit binary random number, valid throughout the vehicle's lifecycle, and strongly bound to the vehicle's primary vehicle identification number (VIN), making it difficult to deduce through algorithms.

[0057] The key is dynamically distributed by the cloud server after receiving the vehicle identification number (VIN) from the electronic testing equipment, using a secure key generation algorithm. It is encrypted and transmitted to the testing equipment, then injected into the hardware security area of ​​the vehicle controller and the module to be authenticated through a secure injection process. During authentication, the key is used to encrypt and decrypt messages, enabling the module to generate a signature and the vehicle controller to verify authenticity, thus confirming that the module has not been replaced or tampered with. The key is stored in the hardware security area, isolated from the ordinary operating system, to prevent software theft. This key ensures that vehicle communication security no longer relies on algorithm confidentiality, but rather on key confidentiality and identity binding.

[0058] The aforementioned encrypted message is a security credential generated by the module to be authenticated in response to an authentication request. It integrates the key, verification information, and vehicle identification number (VIN), serving as proof of identity authenticity and data integrity. The encrypted message is calculated based on the unique key securely stored internally by the module to be authenticated, the verification information provided by the vehicle controller, and the first VIN bound to the module itself. The encrypted message can be a message authentication code generated based on a symmetric encryption algorithm, or it can use encrypted data blocks to ensure that even if intercepted by an attacker, they cannot deduce the key or forge new valid messages.

[0059] The encrypted message binds the identity information of the module to be authenticated with a dynamic challenge, forming a unique credential that ensures session uniqueness for each authentication. The transmission path of the encrypted message relies on the vehicle's internal controller area network bus, and the receiver is the vehicle controller. The entire process is completed in a very short time to ensure that authentication efficiency does not affect vehicle startup speed. The encrypted message effectively resists replay attacks and man-in-the-middle attacks because even if an attacker obtains the message once, they cannot reuse it in subsequent authentications; the randomness of the verification information ensures that the encrypted message is different each time.

[0060] The authentication result described above is the final judgment signal generated by the vehicle controller after verifying the encrypted message. It is not a simple Boolean value, but a system-level decision output carrying the intent of the security strategy, representing an authoritative conclusion as to whether the module to be authenticated has been confirmed as legitimate and trustworthy. Its generation condition is that the vehicle controller successfully decrypts the message and extracts the second vehicle identification code, then compares it bit-by-bit with the first vehicle identification code stored in its own database. Only when they match is the authentication result considered passed; otherwise, it is considered failed. Internally, its content is usually a status flag or security event code, but at the output level, it may be translated into specific action commands such as disconnecting communication, triggering alarms, or disabling functions. Its function is to serve as the triggering basis for subsequent system actions. Once the authentication result is failed, the vehicle controller will immediately cut off the communication link with the module to be authenticated, generate a security message, and notify the display device, thereby achieving a closed-loop response of "detection-isolation-alarm." Its existence is contingent on the vehicle controller independently generating it in the final stage of the authentication process, without relying on external feedback or manual intervention, ensuring its objectivity. Its function is to transform cryptographic verification results into executable system security policies, representing the ultimate embodiment of this patent's "proactive protection" capability. Its significance lies in enabling vehicles to possess self-diagnosis and autonomous defense capabilities, moving beyond passively waiting for malfunctions to occur and instead responding immediately to attacks. The reliability of the authentication results directly determines the trustworthiness of the entire system, serving as the final execution point for implementing a "zero-trust" security architecture in vehicles and the last barrier in the vehicle's security defense line.

[0061] In one alternative embodiment, verification can be based on a symmetric encryption algorithm. For example, the vehicle controller uses its stored key and the received verification information to perform symmetric encryption calculations on the encrypted message, generating a local checksum, which is then compared bit by bit with the authentication code embedded in the encrypted message. Identity is verified through key-driven message digest consistency, ensuring that the message has not been tampered with. This approach improves security due to its low computational overhead, fast execution speed, and the fact that it does not expose the plaintext of the vehicle identification number.

[0062] In another optional embodiment, the vehicle controller uses its stored key to concatenate the verification information with the first vehicle identification number (VIN), inputs it into an encryption engine to generate a fixed-length authentication tag, and then compares it with the authentication tag carried in the encrypted message to obtain the authentication result. By combining the strong obfuscation of block encryption with the integrity protection of the message authentication code, even if an attacker intercepts the message, it will be difficult to generate a matching tag without possessing the key. By binding identity authentication with data integrity, the authentication result not only verifies the module's identity but also ensures that the content stored internally by the vehicle controller has not been tampered with.

[0063] In another optional embodiment, the vehicle controller concatenates the verification information, the first vehicle identification code, and the key, performs a hash operation to generate a local digest value, and compares it with the digest value decrypted from the encrypted message. Consistency verification is achieved through a one-way hash function. Due to its low resource consumption, it is suitable for low-power embedded systems, and even if the encrypted message is intercepted, it is difficult to recover the key. Thus, both security and real-time requirements are met.

[0064] Step S106: Return the authentication result to the module to be authenticated.

[0065] In one optional embodiment, after completing identity verification, the vehicle controller sends the final authentication result back to the module to be authenticated, informing the module that its identity has been confirmed or rejected by the system. This establishes a two-way trust confirmation mechanism, allowing the module to perceive its position within the vehicle system and decide whether to continue subsequent communication. This achieves a two-way interactive and feedback loop in the authentication process, avoiding trust asymmetry caused by one-way verification and ensuring that the module to be authenticated can dynamically adjust its functional permissions based on the authentication result. For example, it can proactively stop remote communication, freeze software upgrade interfaces, or enter a safe mode when authentication fails. By returning the authentication result, the transparency and controllability of the system are improved.

[0066] Authentication results can be transmitted via encryption or a two-way heartbeat confirmation mechanism. Specifically, the vehicle controller uses its private key to digitally sign the authentication result, timestamp, and identifier of the module to be authenticated, generating an authentication confirmation message. This message is then sent to the module to be authenticated, which verifies the signature's validity using a pre-set public key. Alternatively, after sending the authentication result, the vehicle controller requires the module to be authenticated to return a confirmation message containing a random challenge value within a specified time. The vehicle controller then verifies whether the challenge value in this message matches to confirm that the authentication result has been sent to the module. Furthermore, the vehicle controller can write the authentication result to a local security log and synchronize it to the module's internal event buffer via a specific event trigger code. The module can then update its operational status accordingly, such as switching communication modes or disabling remote functionality.

[0067] In this embodiment, the vehicle controller sends an authentication request to the module to be authenticated and receives an encrypted message returned by the module. Based on the verification information, the first vehicle identification code, and the key stored in the vehicle controller, the encrypted message is authenticated to obtain an authentication result. The verification information is generated by the vehicle controller in response to the vehicle's start command, and the authentication result indicates whether the module to be authenticated has passed authentication. The authentication result is then returned to the module to be authenticated. This method involves the vehicle controller actively initiating an authentication request to obtain the encrypted message returned by the module to be authenticated. It then uses the verification information generated during vehicle startup, along with the first vehicle identification code and the key, to authenticate the encrypted message. Because the verification information is dynamically generated, the encrypted message is difficult to replay, ensuring the authenticity of the authentication result and achieving the goal of ensuring vehicle security. This improves vehicle security and solves the technical problem of poor vehicle security.

[0068] Optionally, before receiving the encrypted message returned by the module to be authenticated, the above method further includes: establishing a connection with the electronic inspection device; sending the first vehicle identification code to the electronic inspection device; and receiving the key returned by the electronic inspection device, wherein the key is received from the cloud after the electronic inspection device sends the first vehicle identification code to the cloud, and the first vehicle identification code and the key are associated and stored in the cloud.

[0069] The aforementioned electrical testing equipment is a critical security node in the vehicle production line's off-line phase, serving as the physical messenger connecting the cloud-based key distribution system and the in-vehicle controller. This equipment is a dedicated terminal device with secure authentication and key injection capabilities. Originating from the final electrical testing station in the vehicle manufacturing process, it becomes the execution hub for key lifecycle management. Deployed in a closed, controlled production environment, the equipment establishes encrypted communication with the cloud platform via a secure network and can connect to the vehicle's internal network through an onboard diagnostic system or a dedicated diagnostic interface. The hardware of the electrical testing equipment possesses authentication and secure storage capabilities to prevent malicious replacement or tampering.

[0070] After vehicle assembly, the electronic testing equipment can read the first vehicle identification number (VIN) from the vehicle controller, initiate a key request to the cloud, receive the key returned from the cloud, and inject the key into the secure storage area of ​​the module to be authenticated and the vehicle controller through a security protocol. The electronic testing equipment not only includes a communication protocol stack but also embeds the authentication certificate and key transmission encryption algorithm required for communication with the cloud, thereby ensuring that the "one vehicle, one key" policy is implemented in the physical manufacturing process, achieving a strong binding between the cloud key and the vehicle's identity. The electronic testing equipment eliminates the need for software flashing for authentication, instead completing the process through hardware-level secure injection, enhancing the system's resistance to attacks and achieving tamper-proof authentication.

[0071] The aforementioned cloud platform serves as a trust hub and key management platform, a remote service node independent of the vehicle's local environment, possessing high availability and strong security. The cloud acts as an authoritative database and secure computing center carrying the vehicle's identity and key binding relationships. Deployed in a data center dedicated to the vehicle manufacturer, meeting or exceeding Level 3 of the Information Security Protection System, the cloud possesses physical isolation, access control, encrypted transmission, audit logs, and disaster recovery capabilities. The cloud database employs hardware-encrypted storage, and the mapping between keys and the first vehicle identification number (VIN) is queried by authorized devices. Upon receiving the VIN from the electronic inspection equipment, the cloud dynamically generates a high-strength random key, binds this key to the first VIN, encrypts and stores it, and then transmits it back to the electronic inspection equipment via a secure channel, ensuring that the key is not intercepted or tampered with during transmission.

[0072] The cloud can be configured with a key generation engine, authentication module, device whitelist database, audit log system and remote management interface, so that the keys for each vehicle are no longer pre-set in batches, but are generated, bound and managed independently, avoiding the security risks caused by key leakage.

[0073] In one optional embodiment, before receiving the encrypted message returned by the module to be authenticated, the vehicle controller needs to establish a connection with the electrical testing equipment. This establishes a physical and protocol-level communication link between the vehicle and the dedicated electrical testing equipment on the production line via a diagnostic interface during the vehicle's off-line phase. This creates a secure and reliable communication channel for the subsequent key injection process, ensuring that only authorized production terminals can participate in key distribution and preventing unauthorized devices from stealing or forging keys in the production line environment. This provides a pre-existing trust foundation for key injection, enabling the vehicle controller to verify that the current interaction object is production line equipment, not a tool used by an attacker.

[0074] After establishing a connection with the electronic inspection equipment, the vehicle controller sends the first vehicle identification number (VIN) to the equipment as an index for key requests. This clearly informs the equipment, ensuring the accuracy and uniqueness of subsequent cloud key requests and preventing key mismatches or cross-vehicle injection due to VIN confusion. The VIN serves as the initial credential for key distribution, enabling the equipment to transmit the correct VIN to the cloud, ensuring that the key returned from the cloud is bound to the vehicle. This achieves proactive vehicle identity declaration during the manufacturing process, transforming the vehicle's digital identity from a static label into a dynamic authentication basis.

[0075] After the first vehicle identification number (VIN) is sent to the electronic inspection device, the device obtains a unique encryption key dynamically generated by the cloud. This key is not pre-set but distributed in real time, giving the vehicle controller a unique and random session key for encryption and decryption operations in subsequent vehicle authentication processes. This completes the physical injection loop of the key from the cloud to the vehicle.

[0076] Optionally, before receiving the encrypted message returned by the module to be authenticated, the method further includes: establishing a connection with a diagnostic device, wherein the diagnostic device and the electrical testing device are devices at different nodes in the production line; receiving a registration request sent by the diagnostic device, wherein the registration request is generated based on the private key of the diagnostic device; verifying the diagnostic device based on the registration request and the public key corresponding to the diagnostic device, and obtaining a verification result, wherein the public key is pre-programmed into the hardware security area in the vehicle controller, and the verification result is used to characterize whether the vehicle controller has passed the verification; if the verification result indicates that the vehicle controller has passed the verification, receiving and storing the first vehicle identification code sent by the diagnostic device.

[0077] The aforementioned diagnostic equipment serves as a secure interaction node in the vehicle manufacturing process, acting as a front-end tool within the authentication system responsible for initial vehicle registration and hardware authenticity verification. This diagnostic equipment is a dedicated production terminal with secure authentication capabilities, private key storage, and protocol encryption. Deployed on the production line, it establishes a physical connection with the vehicle controller. The private key stored within the diagnostic equipment can be uniformly issued by the manufacturer and paired with the pre-installed public key in the vehicle controller, preventing unauthorized devices from initiating the registration process.

[0078] After the vehicle assembly is completed, the diagnostic equipment can send a registration request to the vehicle controller through the diagnostic interface. This request is signed by the internal private key of the diagnostic equipment. The vehicle controller uses the built-in public key to verify the legitimacy. Only after confirming that the source of the equipment is trustworthy will it allow the receipt and writing of the first vehicle identification code to the internal secure storage area.

[0079] Diagnostic equipment may involve security protocol stacks, digital signature modules, hardware security chips, and communication interfaces. Its software firmware is uniquely signed to prevent tampering or replacement. Diagnostic equipment can ensure that the vehicle controller and communication module have been officially certified before each vehicle enters the production line, preventing non-original hardware or counterfeit modules from entering the production line.

[0080] The aforementioned private key is used in the diagnostic device to generate the registration request and is a core confidentiality element in the digital signature system. The private key can be a uniquely generated asymmetric encryption private key generated by the vehicle manufacturer during device manufacturing and burned into the hardware security chip. The private key can be a random number of at least 256 bits, paired with a pre-installed public key in the vehicle controller, and each diagnostic device has a unique private key, ensuring the uniqueness of the device's identity. The private key is stored in the hardware security module inside the diagnostic device, making it difficult to read, export, or copy via software. Even if the device casing is disassembled, the private key content cannot be extracted.

[0081] The private key provides digital signature capabilities for registration requests. The vehicle controller verifies the signature using the public key to confirm the authenticity of the device's origin, thereby ensuring that only authorized production tools can inject identity information into the vehicle and preventing third-party devices from impersonating production line equipment to write data.

[0082] The aforementioned registration request is the initial authentication message initiated by the diagnostic device to the vehicle controller. The registration request can be a digital credential signed with a secure private key, used to prove that it is a production-authorized device. After physically connecting to the vehicle, the diagnostic device first reads its proprietary private key from its internal secure area, and then digitally signs the raw data containing the device identifier, timestamp, and instruction code to form the registration request. The registration request may include, but is not limited to, a signature algorithm identifier, signature data, device serial number, and the purpose of the request. The structure of the registration request conforms to the vehicle secure communication protocol standard to prove its identity to the vehicle controller, confirming that it is not a forged device by an attacker, thereby gaining the permission to subsequently write to the first vehicle identification number (VIN).

[0083] Registration requests can be generated by the diagnostic device within its hardware security module, and each registration request is unique and time-sensitive to prevent replay attacks. Registration requests establish bidirectional trust between the diagnostic device and the vehicle controller. Only after private key verification is the vehicle controller allowed to receive the first vehicle identification number, ensuring the controllability and traceability of the identity injection process.

[0084] The aforementioned public key is a pre-installed public key within the vehicle controller used to verify the legitimacy of registration requests from diagnostic devices. This public key is generated in pairs with the private key held by the diagnostic device and is securely programmed into the hardware security area by the vehicle manufacturer before the controller chip leaves the factory. The public key is written by the manufacturer using a trusted programming device during the vehicle controller production phase. The public key can be used to verify the digital signature of registration requests from diagnostic devices, ensuring that the authentication request was indeed generated by a legitimate device possessing the corresponding private key, thereby preventing any device from impersonating production line tools to write the request.

[0085] The verification result described above is the judgment value obtained by the vehicle controller after receiving the registration request from the diagnostic device, using its built-in public key to verify the signature. The verification result is a system-level security decision signal representing whether the device's identity has been verified. If the verification result is successful, the vehicle controller will receive and store the first vehicle identification code sent by the diagnostic device; otherwise, it will immediately terminate communication and issue an alarm. The verification result ensures that authorized production line equipment participates in vehicle identity registration, preventing other devices from tampering with vehicle identity information or injecting forged first vehicle identification codes.

[0086] In one optional embodiment, before receiving the encrypted message returned by the module to be authenticated, the vehicle controller needs to establish a connection with the diagnostic equipment. That is, after the vehicle is assembled and before entering the offline key injection stage, the vehicle controller establishes a secure communication channel with the diagnostic tools on the production line to establish a trusted interaction path at the physical and protocol levels for the subsequent identity registration process. This ensures that authorized production line equipment can communicate with the vehicle controller and prevents other tools from accessing and tampering with the vehicle's identity information.

[0087] After establishing a connection with the diagnostic equipment, the vehicle controller receives a registration request from the diagnostic equipment, confirming that the currently connected diagnostic equipment is a manufacturer-authorized production tool, and not a third-party device forged or stolen by an attacker. This triggers the vehicle controller's public key verification process, enabling the vehicle controller to perform asymmetric encryption-level identity authentication of the registration request source using a pre-set public key, thereby ensuring the legitimacy of subsequent operations.

[0088] Upon receiving a registration request, the vehicle controller verifies the diagnostic device using the request and its pre-installed public key. This verifies whether the device was issued with a legitimate private key, confirming its identity and ensuring it possesses a unique key pair issued by the manufacturer. This grants the device the authority to perform critical operations on the production line. By establishing a one-way trust relationship between the vehicle controller and the diagnostic device, the vehicle controller can independently perform security checks in an offline environment without network dependence.

[0089] Only when the verification result indicates that the vehicle controller has passed the verification will the vehicle controller allow the receipt and writing of the vehicle's first vehicle identification code to the vehicle controller's internal secure storage area. This ensures that the initial registration of the vehicle's identity is performed with the participation of authorized devices, preventing the first vehicle identification code from being tampered with, copied, or mismatched due to device hijacking or impersonation.

[0090] This step solidifies the vehicle's digital identity, binding the first vehicle identification code to the vehicle controller hardware. This code then serves as the basis for subsequent key injection, runtime authentication, and full lifecycle traceability, ensuring that the identity of each vehicle is traceable and building a tamper-proof vehicle security system.

[0091] Optionally, based on the verification information, the first vehicle identification code stored in the vehicle controller, and the key, the encrypted message is authenticated to obtain the authentication result, including: decrypting the encrypted message based on the key and verification information to obtain the second vehicle identification code; and obtaining the authentication result based on the second vehicle identification code and the first vehicle identification code.

[0092] The aforementioned second vehicle identification number (VIN) is an identity identifier extracted by the vehicle controller after the module to be authenticated embeds its own stored VIN into the encrypted message content. This second VIN is compared with the first VIN stored locally by the vehicle controller. The second VIN is actively extracted by the module to be authenticated during the encryption process. It is decrypted by the vehicle controller using a key and used as the basis for identity verification to determine whether the module to be authenticated is bound to a vehicle. The second VIN is generated by the module to be authenticated in a secure environment and obtained through key decryption, making it impossible to obtain through guessing or cracking. The second VIN eliminates the reliance on module hardware model or serial number for authentication, directly binding it to the actual vehicle identity. Even if an attacker installs the module to be authenticated into another vehicle, authentication will be difficult to pass.

[0093] In one optional embodiment, the vehicle controller uses its own securely stored unique key and the random verification information generated during the authentication process as decryption parameters to perform reverse cryptographic operations on the encrypted message from the module to be authenticated, thereby restoring the second vehicle identity carried in the message. By extracting the vehicle identity claimed by the module to be authenticated from the encrypted data, rather than directly trusting the original transmitted content, it ensures that the obtained second vehicle identity is not plaintext data that has been tampered with or forged. This achieves dual verification of content trustworthiness and identity verifiability. Decryption can only be successful if the key is correct and the verification information matches, thus eliminating attack methods such as replay attacks, man-in-the-middle substitution, or simple data injection.

[0094] Then, the vehicle controller decrypts the second vehicle identification number (VIN) from the encrypted message and matches it with the first VIN stored in its own hardware to confirm whether the identity claimed by the module to be authenticated matches the true identity of the current vehicle. This determines whether the module to be authenticated is an original factory-bound component that has not been replaced. This gives the system "anti-porting" capability; because the bound VIN is inconsistent, it will still be rejected by the system, thus completely avoiding high-risk attacks such as module misappropriation and counterfeiting, and helping to achieve the security goal of one vehicle, one password, and lifelong binding.

[0095] For example, based on a checksum-based integrity comparison, a checksum value can be calculated for the first vehicle identification code and stored together. After decrypting the second vehicle identification code, the checksum value is calculated similarly. By comparing whether the checksum values ​​match, the authentication result is obtained. Indirectly confirming identity consistency through mathematical digests reduces storage and transmission overhead, while simultaneously improving resistance to random disturbances, preventing misjudgments caused by communication noise or storage bit flips, and enhancing system robustness.

[0096] Alternatively, hash fingerprint comparison can be used. The first and second vehicle identification codes are subjected to the same hash operation, compressing the vehicle identification codes into a fixed-length digest. This avoids plaintext comparison and enhances resistance to side-channel attacks. Thus, the authentication result is obtained by comparing the hash values.

[0097] Preferably, the authentication result is obtained based on the second vehicle identification code and the first vehicle identification code, including: if the second vehicle identification code and the first vehicle identification code are consistent, the authentication result indicates that the module to be authenticated has passed the authentication; if the second vehicle identification code and the first vehicle identification code are inconsistent, the authentication result indicates that the module to be authenticated has failed the authentication.

[0098] In one optional embodiment, if the second vehicle identification number (VIN) matches the first VIN, it is determined that the module to be authenticated is a legitimate component originally bound to the vehicle at the factory, and has not been replaced or ported, ensuring a strong binding relationship between the module and the vehicle. Only when the module to be authenticated passes authentication is the system triggered to allow the module to continue participating in key functions such as communication, software upgrades, and remote control.

[0099] If the second vehicle identification number (VIN) does not match the first VIN, the module can be determined to be a replaced or unauthorized device from another vehicle. By quickly identifying and isolating potential attack vectors, malicious modules can be prevented from penetrating the vehicle network through forged communication protocols or man-in-the-middle attacks. This can trigger security response mechanisms, such as severing module communication permissions, disabling remote functions, recording security events, and triggering instrument panel alarms, achieving proactive defense through detection and isolation.

[0100] Optionally, after authenticating the encrypted message based on the verification information, the first vehicle identification code and key stored in the vehicle controller, and obtaining the authentication result, the above method further includes: disconnecting the connection with the module to be authenticated and generating a security message if the authentication result indicates that the module to be authenticated has failed authentication; and sending the security message to the display device.

[0101] The aforementioned security message is a system-level security event notification message generated by the vehicle controller when authentication fails. A security message is an encrypted or signed security instruction with high priority and clear semantics, used to trigger the vehicle's defense-in-depth mechanism. The security message is generated when authentication fails and the vehicle controller has confirmed that the module to be authenticated does not have authorized status. The system proactively triggers a security response process to generate this security message. The security message may contain, but is not limited to, structured information such as event type, timestamp, fault code, device identifier, and security level, to convey to other vehicle controllers and the human-machine interface system that the module to be authenticated is not authorized, serving as the trigger for subsequent isolation and alarm execution. This achieves an automated closed loop, enabling the vehicle to notify the driver and cut off dangerous communication paths immediately when attacked. It also gives the vehicle the ability to self-recognize its security status, transforming previously hidden system anomalies into perceptible user warnings, achieving human-machine collaborative security, and improving user awareness and security response speed.

[0102] The aforementioned display devices serve as the vehicle's human-machine interface, such as the instrument panel or central control screen. These devices can display safety alarms and enhance user awareness. They possess graphical display capabilities, high-priority warning prompts, and support safety event rendering protocols.

[0103] Upon receiving a safety message from the vehicle controller, the display device visually presents a clear warning to the driver, such as a flashing icon, a text prompt "Communication system malfunction" or "Please go to the service center," ensuring that the user is aware of the change in the system's safety status immediately. This display device makes the safety mechanism perceptible, preventing users from being left unnoticed even after the communication module has been replaced, thereby reducing potential risks and enabling the vehicle to not only have defensive capabilities but also informational capabilities, thus achieving a safety upgrade.

[0104] In one optional embodiment, if the authentication result indicates that the module to be authenticated has failed authentication, the application layer and some underlying communication links between the module and the vehicle controller can be terminated through software logic or hardware control mechanisms. This includes interactions such as message transmission and reception on the bus and service request / response. This prevents unauthorized modules from continuing to participate in critical vehicle functions and prevents the module to be authenticated from acting as a springboard for malicious attacks, such as forging remote start, tampering with location data, or stealing user privacy. This achieves proactive isolation, confining threats to a single module and preventing impact on core systems such as the gateway, autonomous driving domain, or power battery.

[0105] Upon disconnection, a security message is generated. This message can include structured events such as timestamps, error codes, module identifiers, and authentication status. The security message can be generated using encryption or signing. This provides accurate and reliable evidence of failure for subsequent remote diagnostics or software policy updates, transforming a local authentication failure into a traceable, reportable, and analyzable security event. It also supports attack pattern analysis, batch risk warnings, and recall decisions in the cloud.

[0106] Furthermore, security messages can be sent to display devices to transmit security events in standard diagnostic or user-generated prompt formats to the instrument panel, central control screen, and other human-machine interfaces, triggering clear visual or audible warnings. This delivers clear safety alerts to the driver, such as "communication module malfunction" or "vehicle authentication failed," preventing users from continuing to use potentially risky vehicles without their awareness. This achieves human-machine collaborative defense, enhancing user safety awareness and trust.

[0107] According to an embodiment of this application, a method embodiment for authenticating a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0108] This embodiment provides a vehicle authentication method. Figure 2 This is a flowchart of a vehicle authentication method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0109] Step S202: Receive the authentication request sent by the vehicle controller and obtain the verification information from the authentication request.

[0110] Step S204: Based on the verification information, the first vehicle identification code and key stored in the module to be authenticated, generate an encrypted message.

[0111] The vehicle controller is deployed in the vehicle, and encrypted messages are used to authenticate the module to be authenticated through the vehicle controller.

[0112] Step S206: Send the encrypted message to the vehicle controller and receive the authentication result returned by the vehicle controller.

[0113] The authentication result is used to indicate whether the module to be authenticated has passed the authentication.

[0114] The authentication module in this method can listen for authentication requests from the vehicle controller and extract verification information from the requests to respond to the authentication process initiated by the controller, ensuring that the authentication is a real-time, non-replay interaction. This provides input for the generation of subsequent encrypted messages, ensuring the authenticity of the output results of each authentication, thereby effectively defending against replay attacks.

[0115] Then, using the unique key bound to its secure storage area and the first vehicle identification number, combined with the received verification information, a unique encrypted message is generated through a combination operation using a symmetric encryption algorithm or a hash algorithm. This cryptographically proves that the module possesses identity credentials, rather than simply transmitting plaintext information. By binding the module's identity, key, and the current session into a high-entropy encrypted product, it ensures that only modules holding the correct key can generate valid messages.

[0116] Therefore, the encrypted message is sent back to the vehicle controller, and the system listens for the final authentication result returned by the controller after verifying the message, thus completing the authentication process loop. This allows the module to be authenticated to know whether it has been recognized by the system, and thus decide on its subsequent behavior (such as continuing to work or entering a safe sleep state). By implementing two-way confirmation, authentication is not only a unilateral judgment by the vehicle controller, but also a mutual confirmation between the module and the vehicle controller.

[0117] According to an embodiment of this application, an embodiment of a vehicle authentication system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0118] This embodiment provides a vehicle authentication system. Figure 3 This is a schematic diagram of a vehicle authentication system according to an embodiment of this application, such as... Figure 3 As shown, the system includes the following:

[0119] The module to be authenticated 302 is deployed in the vehicle. The module to be authenticated is used to receive the authentication request sent by the vehicle controller and obtain the verification information from the authentication request. Based on the verification information, the first vehicle identification code and key stored in the module to be authenticated, it generates an encrypted message, sends the encrypted message to the vehicle controller, and receives the authentication result returned by the vehicle controller. The encrypted message is used to authenticate the module to be authenticated by the vehicle controller, and the authentication result is used to indicate whether the module to be authenticated has passed the authentication.

[0120] The vehicle controller 304 is deployed in the vehicle. The vehicle controller is used to send authentication requests to the module to be authenticated and receive encrypted messages returned by the module to be authenticated. Based on the verification information, the first vehicle identification code and key stored in the vehicle controller, the encrypted messages are authenticated to obtain the authentication result. The authentication result is returned to the module to be authenticated. The verification information is generated by the vehicle controller in response to the vehicle's start command.

[0121] In this authentication system, the module to be authenticated receives the authentication request sent by the vehicle controller and obtains verification information from the request. This ensures that the authentication process is real-time and non-repetitive, preventing attackers from intercepting and replaying historical messages. Then, based on the verification information, the stored first vehicle identification number, and the key, it generates an encrypted message to prove its identity. The module to be authenticated sends the encrypted message to the vehicle controller and receives the authentication result returned by the controller, thus determining whether it has been recognized by the system. This forms a complete two-way communication loop, ensuring that authentication is not a one-sided judgment but a consensus process confirmed by both parties.

[0122] In this authentication system, the vehicle controller sends authentication requests to the modules to be authenticated, proactively triggering identity verification of the communication modules when the vehicle is powered on and started, ensuring that critical communication units are in a trusted state before their functions are enabled. This security strategy is implemented by embedding the authentication process into the system startup flow.

[0123] The vehicle controller can authenticate encrypted messages based on verification information, its own stored first vehicle identification code, and key. It independently reproduces the encryption operation to obtain the authentication result, thereby confirming the authenticity of the module to be authenticated. This achieves local closed-loop authentication without relying on the cloud or external devices, ensuring low latency and high availability. The vehicle controller also returns the authentication result to the module to be authenticated, informing it whether it can continue to participate in vehicle communication and function calls, thus achieving state synchronization between the module to be authenticated and the vehicle controller.

[0124] Optionally, the system further includes: a diagnostic device, which, after establishing a connection with the vehicle controller, generates a registration request based on the private key stored in the diagnostic device, sends the registration request to the vehicle controller, receives the verification result returned by the vehicle controller, and, if the verification result indicates that the vehicle controller has passed the verification, writes the first vehicle identification code into the module to be authenticated and the vehicle controller.

[0125] The diagnostic device establishes a physical and protocol-level communication link with the vehicle controller, ensuring the security and stability of the data transmission channel. This creates a trusted local communication environment for subsequent key verification and identity injection operations, preventing unauthorized device access. The diagnostic device can then generate a registration request based on its stored private key, forming a registration request with identity authentication and integrity protection. This proves to the vehicle controller that the diagnostic device is an authorized and legitimate production line tool, not a forged device created by an attacker. Furthermore, if the verification result indicates that the vehicle controller has passed the verification, it confirms that the vehicle controller has also completed the identity verification of the diagnostic device, ensuring mutual trust. The first vehicle identification number (VIN) is then written to both the authentication module and the vehicle controller to complete the vehicle's identity registration.

[0126] Preferably, the system further includes: an electrical testing device, which, after establishing a connection with the vehicle controller, reads the first vehicle identification code, generates a key request based on the first vehicle identification code, sends the key request to the cloud, receives the key returned by the cloud, and injects the key into the module to be authenticated and the vehicle controller.

[0127] The electrical testing equipment establishes a secure, stable, and auditable communication link with the vehicle's controller, ensuring that data interaction occurs only between authorized equipment and legitimate vehicles. This establishes a trusted local communication channel for subsequent key distribution processes, preventing unauthorized equipment access or data interception.

[0128] The electrical inspection equipment reads the first vehicle identification number (VIN) to obtain the vehicle's identity certificate. This certificate serves as an index for requesting a key from the cloud, ensuring that the key request is accurately bound to the specific vehicle and preventing mismatches that could lead to incorrect key distribution. For example, a key request can be generated based on the first VIN, carrying additional information such as equipment identity, production line number, and timestamp. This request is then sent to the cloud, triggering the cloud's key generation and binding process. By activating the cloud's dynamic key distribution mechanism, keys are no longer pre-set or batch-programmed; instead, they are generated on demand, vehicle-specific, and in real-time.

[0129] After receiving the key returned from the cloud, the key is injected into the module to be authenticated and the vehicle controller, realizing two-point secure distribution of the key at the vehicle end, ensuring that both parties to the authentication have the same key material, so that the key is securely solidified before leaving the factory and is not exposed in plaintext.

[0130] The technical solution proposed in this application will be described below with reference to an optional embodiment. This application proposes a hardware and software anti-tampering authentication method and system for key electronic control units in intelligent connected vehicles.

[0131] Taking the in-vehicle information and communication module as an example, this paper introduces a security authentication method and system that runs through the entire lifecycle of the module, from manufacturing and off-line activation to vehicle operation. This method, through collaboration between the cloud and the vehicle, dynamically injects a unique key into each vehicle during the production line stage. Then, each time the vehicle starts, it performs real-time identity verification based on a challenge-response mechanism, thereby achieving proactive and continuous security protection for the module.

[0132] Because authentication relies on pre-set, fixed passwords, serial numbers, or simple checksums within the module software, the authenticator determines the module's legitimacy by reading and comparing this static information. Runtime authentication focuses on communication security, but the source and distribution process of the trust root (key) it relies on may be risky, and the authentication process is decoupled from production information.

[0133] This invention addresses the systemic and fundamental problems in the anti-tampering authentication of in-vehicle information and communication modules in the field of intelligent connected vehicles. While current defenses often rely on isolated, point-like measures, this embodiment constructs a chain-like trust system spanning the entire vehicle manufacturing and usage lifecycle. Against pre-programmed fixed keys or unified algorithms, attackers can easily replicate modules on a large scale once the key is cracked or extracted from a single device. This embodiment enables low-cost, highly secure dynamic key management with a unique key for each vehicle, ensuring that each vehicle's key is dynamically generated and strongly bound to the vehicle's identity.

[0134] The hardware authenticity verification during production, the software flashing during off-line processing, and the identity authentication during operation are all disconnected. The subsequent behavior of a module off the production line cannot be continuously traced. This embodiment can seamlessly and reliably link the module's initial trusted identity at the production end with its continuous operational authentication at the vehicle end, establishing a complete and reliable chain of evidence.

[0135] The key injection process often lacks a strong association with the vehicle's unique identifier under the control of a trusted third party (cloud). This could result in other modules remaining usable even after the vehicle is replaced. This embodiment enables real-time, secure, one-to-one strong binding and distribution of the key and the vehicle's unique identifier (i.e., the first vehicle identification code in the above embodiment) under authoritative cloud management, ensuring that the key is permanently bound to the vehicle and preventing the module from being ported or misappropriated.

[0136] To address the lack of an integrated failure handling mechanism, this embodiment immediately implements automated safety isolation and explicit human-machine interaction alarms upon real-time verification failure at the vehicle end. This achieves a rapid, automatic response loop, minimizing the impact of potential risks and clearly alerting the user.

[0137] This allows for a systematic solution to key issues in the entire trust chain, from cloud-based key production and binding to secure injection off-line and real-time challenge response and failure handling on the vehicle side. Consequently, it provides a proactive and trustworthy anti-tampering method covering the entire lifecycle for the core communication modules of intelligent connected vehicles.

[0138] In other words, this embodiment can construct a complete trusted chain from the cloud, off the production line to vehicle operation, and achieve proactive and efficient hardware and software protection through a combination of cloud collaboration, dynamic keys and real-time verification.

[0139] Specifically, such as Figure 4 The diagram illustrates an optional end-to-end vehicle authentication method. This method involves three phases: the first phase is production initialization and identity binding; the second phase is dynamic distribution of production offline keys; and the third phase involves real-time challenge response and proactive protection.

[0140] By initializing production and binding identities, such as pre-setting a unified public key during module production, and then assembling the module into the vehicle, initial authentication is completed via diagnostic equipment, and the vehicle's unique identification code is written to establish initial trust.

[0141] Specifically, such as Figure 5 The diagram illustrates an optional authentication method for the vehicle production stage. This method includes: the supplier programming the public key and algorithm into the body controller and information communication module. After the body controller and information communication module are assembled into the vehicle, they undergo initial authentication by diagnostic equipment. The diagnostic equipment uses its private key to challenge the system, while the body controller verifies the public key. If verification is successful, the diagnostic equipment is authorized to write the vehicle's unique identification code. If verification fails, an error is reported to the production line, and the system is blocked.

[0142] The production line offline key is dynamically distributed. For example, when a vehicle rolls off the production line, the electrical inspection equipment sends the vehicle's unique identification code to the cloud. The cloud dynamically generates a unique key for each vehicle and securely stores the vehicle's unique identification code and the key after strong binding. Subsequently, this key is securely injected into the vehicle's secure storage areas such as the body controller and information communication module, achieving "one key per vehicle".

[0143] Specifically, such as Figure 6 The diagram illustrates an optional authentication method for vehicles off-line. This method includes: an electronic inspection device reading the vehicle's unique identification code and requesting a key; the vehicle cloud platform generating the key and associating it with the vehicle's unique identification code, storing it in a cloud database; and the vehicle cloud platform distributing the key to the electronic inspection device, which then securely injects the key into secure in-vehicle storage areas such as the body controller and information communication module.

[0144] The system implements real-time challenge response and proactive protection. For example, each time the vehicle starts, the body controller generates a random number to initiate a challenge. The information communication module uses its stored vehicle unique identifier, key, and random number to generate an encrypted message (response) and returns it. The body controller decrypts and verifies whether the vehicle unique identifier in the message matches its stored identifier. If the verification passes, normal communication occurs; if the verification fails, it is immediately identified as tampering, and interaction with the module is proactively severed, with a clear warning issued to the driver via the instrument panel. This achieves a highly reliable and perceptible anti-tampering method through centralized key management and lifecycle binding in the cloud, combined with a lightweight real-time challenge response mechanism on the vehicle side.

[0145] Specifically, such as Figure 7 The diagram illustrates an optional authentication method for vehicle operation. This method includes: after vehicle startup, the body controller generates a random number and challenges the communication module. The communication module uses the vehicle's unique identification code, a key, and the random number to generate and return an encrypted message. The body controller decrypts the message and verifies whether the vehicle's unique identification code in the encrypted message matches the code stored in the body controller. If the verification succeeds, normal communication occurs; if the verification fails, a security policy is implemented, such as actively severing interaction with the module and issuing a clear warning to the driver via the instrument panel, displaying a fault warning.

[0146] The cloud-based authoritative binding and vehicle-side real-time verification framework in this embodiment is not only applicable to information communication modules, but can also be used to authenticate gateway controllers, autonomous driving domain controllers, etc., thereby building a secure network within the entire vehicle.

[0147] In addition, this embodiment also constructs a secure trust chain from the cloud to the vehicle, covering the production and operation processes. The system includes: a vehicle cloud platform, vehicle factory electrical testing equipment, a body controller, an information communication module, and an instrument display.

[0148] The vehicle cloud and electrical testing equipment can be connected via a wide area network (WAN) to form a cloud-based command channel for the production process. Internal vehicle controllers are connected via a highly reliable controller area network (CLAN) bus, forming an in-vehicle safety communication and verification network. This integrated internal and external architecture ensures that safety strategies are implemented from the manufacturing stage throughout the entire vehicle lifecycle.

[0149] The vehicle cloud platform, serving as the system's trust anchor, is deployed on the vehicle manufacturer's server. It not only generates and manages the core key materials for the entire system but also maintains an authoritative mapping database of vehicle identification numbers (VINs) and critical encryption keys for each vehicle. This allows it to respond to key distribution requests during the production line rollout process.

[0150] The vehicle factory electrical testing equipment is located at a critical node in the vehicle production workshop. This equipment has dual interfaces: one connects to the vehicle cloud platform via a cellular network or a secure wired network; the other connects to the vehicle's internal network via a standard diagnostic interface and dedicated diagnostic equipment. This allows it to securely receive keys from the vehicle cloud during the final inspection stage before the vehicle rolls off the assembly line and inject those keys into the designated onboard controller.

[0151] The body controller is one of the key domain controllers in the vehicle's electronic and electrical architecture. It not only stores its own identity code and key, but also proactively initiates an authentication challenge against the information communication module each time the vehicle starts, ultimately authenticating the module and executing corresponding security policies.

[0152] The information and communication module is the core protected component of the system. It integrates functions such as cellular communication and positioning, and is a key component for enabling remote vehicle control, software upgrades, and data uploads. The information and communication module securely stores its own identity and key, and can respond to challenges from the vehicle's control system.

[0153] As the main interface for interaction between the system and the driver, the instrument display can receive authentication result instructions from the body controller and clearly convey the status of the information communication module to the driver in a visual manner (such as icons and text warnings), thereby improving the system's perceptibility.

[0154] The operation of this system can be divided into three stages.

[0155] Phase one involves production initialization and identity injection. This means the foundation of trust begins in the manufacturing process. At the chip-level suppliers of the body controller and information communication modules, a unified public key for an asymmetric cryptographic algorithm is pre-programmed into the hardware security area during production. This public key and the corresponding authentication algorithm are already fixed during the chip design phase, establishing an initial point of trust for subsequent processes.

[0156] When these modules are assembled into the vehicle and enter the pre-production stage, the diagnostic equipment on the production line connects to the vehicle network through a diagnostic port. The diagnostic equipment uses a pre-set private key (paired with the public key in the onboard module) to initiate an initial authentication challenge to the body controller. The body controller uses its internal public key to verify the challenge and returns the result. If verification fails, the production line system immediately alarms, preventing the vehicle from proceeding to the next stage. Upon successful verification, the diagnostic equipment is authorized to officially write this globally unique vehicle identification number into the non-volatile secure storage area of ​​the body controller and the information communication module, completing the registration of its digital identity.

[0157] Phase Two involves the dynamic distribution and secure injection of keys off the production line, a crucial step in connecting the cloud and the vehicle to achieve "one key per vehicle." At the final electrical inspection station, the electrical inspection equipment reads the vehicle identification number (VIN) through the diagnostic port. Subsequently, using this VIN as an index, the equipment requests a unique symmetric encryption key from the vehicle-to-cloud platform via a secure channel. Upon receiving the request, the vehicle-to-cloud platform's security server verifies its legitimacy (e.g., the electrical inspection equipment's identity, production batch, etc.). A random key is dynamically generated for the VIN (or allocated from a secure pool). The VIN-key pair is securely stored in the cloud database for future verification or to support security services. The VIN is then transmitted back to the electrical inspection equipment in the workshop via an encrypted channel. After securely receiving the key, the electrical inspection equipment can use a diagnostic protocol to securely write the key into the secure storage areas of the body controller, information communication module, and instrument display.

[0158] Phase three involves real-time challenge response and proactive protection during vehicle operation. After the vehicle is delivered to the user, the system enters a normalized proactive protection mode. Each time the vehicle starts, the body controller automatically performs an authentication of the information communication module: A challenge is initiated by the body controller generating a random number and sending it to the information communication module via the bus. This random number ensures that each authentication session is unique, preventing replay attacks. A credential is generated by the information communication module receiving the random number and using its internal security algorithm to perform a mixed operation with its stored vehicle identification code-key and the received random number to generate an encrypted message (i.e., a digital signature). A response is verified by the information communication module sending this encrypted message back to the body controller via the bus. The body controller uses its stored key and the previously sent random number to decrypt and verify the message, extracting the vehicle identification code. Finally, the body controller compares the decrypted vehicle identification code with its stored vehicle identification code. If they match, it indicates that the information communication module is authentic, the software is intact, and the key is correct; verification is successful, and normal communication between the two parties resumes. If the comparison fails, the vehicle controller will immediately determine that the information communication module may have been attacked by hardware replacement, software tampering, or key leakage.

[0159] If an anomaly is detected, the system will activate a pre-defined defense-in-depth strategy. For example, the body controller will immediately sever application-layer data interaction with the problematic information communication module, logically isolating the module to prevent potential malicious commands. Simultaneously, the body controller will send the authentication failure result as a high-priority security event message to the instrument cluster display on the bus. The instrument cluster display will then illuminate a specific warning icon (such as "Communication System Failure") and, if possible, display a concise message informing the driver that the system has detected an anomaly and suggesting contacting a service provider. This coordinated mechanism enhances the system's proactive defense capabilities and user awareness.

[0160] This system enables full lifecycle security management, covering the entire information and communication module process from supply chain pre-installation and off-line injection to vehicle usage cycle verification, achieving a secure closed loop. Furthermore, the cloud dynamically distributes unique keys to each vehicle, increasing the cost and difficulty for attackers to perform mass cracking or impersonation. Hardware-level secure storage is implemented, such as storing keys in a secure hardware area of ​​the controller, isolated from the normal operating environment, effectively resisting software detection and extraction. It also enables lightweight and efficient authentication mechanisms, such as using a challenge-response model of symmetric cryptography, achieving low-overhead, high-speed real-time authentication in resource-constrained in-vehicle network environments. Additionally, through explicit failure handling strategies, such as logical isolation and user alerts, the impact of potential risks is reduced.

[0161] Therefore, this system not only directly protects the information communication module and vehicle data security, but also serves as a trusted root of the vehicle's security architecture, providing underlying security trust guarantees for advanced autonomous driving functions, V2X vehicle-to-everything (V2X) collaboration, and data-based value-added services. This authentication method can be embedded in active safety defense systems within production facilities and vehicles.

[0162] It should be noted that the user information (including but not limited to user device information) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0163] According to an embodiment of this application, a device embodiment for a vehicle authentication apparatus is provided. It should be noted that the apparatus can be used to perform the above-described vehicle authentication method.

[0164] This embodiment provides a vehicle authentication device. Figure 8 This is a schematic diagram of a vehicle authentication device according to an embodiment of this application, such as... Figure 8 As shown, the device includes the following:

[0165] The transmission module 82 is used to send authentication requests to the module to be authenticated and to receive encrypted messages returned by the module to be authenticated.

[0166] The authentication module 84 is used to authenticate encrypted messages based on verification information, the first vehicle identification code and key stored in the vehicle controller, and obtain authentication results. The verification information is generated by the vehicle controller in response to the vehicle's start command, and the authentication results are used to characterize whether the module to be authenticated has passed the authentication.

[0167] Return module 86 is used to return the authentication result to the module to be authenticated.

[0168] Optionally, before receiving the encrypted message returned by the module to be authenticated, the above device further includes a construction module for: establishing a connection with the electronic inspection equipment; sending the first vehicle identification code to the electronic inspection equipment; and receiving the key returned by the electronic inspection equipment, wherein the key is received from the cloud after the electronic inspection equipment sends the first vehicle identification code to the cloud, and the first vehicle identification code and the key are associated and stored in the cloud.

[0169] Optionally, before receiving the encrypted message returned by the module to be authenticated, the above-mentioned device further includes a registration module, configured to: establish a connection with the diagnostic device, wherein the diagnostic device and the electrical testing device are devices at different nodes in the production line; receive a registration request sent by the diagnostic device, wherein the registration request is generated based on the private key of the diagnostic device; verify the diagnostic device based on the registration request and the public key corresponding to the diagnostic device, and obtain a verification result, wherein the public key is pre-programmed into the hardware security area in the vehicle controller, and the verification result is used to characterize whether the vehicle controller has passed the verification; and if the verification result characterizes that the vehicle controller has passed the verification, receive and store the first vehicle identification code sent by the diagnostic device.

[0170] Optionally, the authentication module is further configured to: decrypt the encrypted message based on the key and verification information to obtain a second vehicle identification code; and obtain an authentication result based on the second vehicle identification code and the first vehicle identification code. Preferably, the authentication module is configured to: determine that the authentication result indicates that the module to be authenticated has passed authentication if the second vehicle identification code and the first vehicle identification code are consistent; and determine that the authentication result indicates that the module to be authenticated has failed authentication if the second vehicle identification code and the first vehicle identification code are inconsistent.

[0171] Optionally, after authenticating the encrypted message based on the verification information, the first vehicle identification code and key stored in the vehicle controller, and obtaining the authentication result, the above device further includes a display module, used to: disconnect the connection with the module to be authenticated and generate a security message if the authentication result indicates that the module to be authenticated has failed authentication; and send the security message to the display device.

[0172] According to an embodiment of this application, an embodiment of a vehicle authentication device is provided. It should be noted that the device can be used to perform the above-described vehicle authentication method.

[0173] This embodiment provides a vehicle authentication device. Figure 9 This is a schematic diagram of a vehicle authentication device according to an embodiment of this application, such as... Figure 9 As shown, the device includes the following:

[0174] The transmission module 92 is used to receive the authentication request sent by the vehicle controller and obtain the verification information from the authentication request.

[0175] The generation module 94 is used to generate an encrypted message based on the verification information, the first vehicle identification code and key stored in the module to be authenticated, wherein the vehicle controller is deployed in the vehicle, and the encrypted message is used to authenticate the module to be authenticated through the vehicle controller.

[0176] The receiving module 96 is used to send encrypted messages to the vehicle controller and receive the authentication result returned by the vehicle controller. The authentication result is used to indicate whether the module to be authenticated has passed the authentication.

[0177] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0178] This application also provides an electronic device 90, please refer to... Figure 10 It includes a memory 910 and a processor 920, wherein the memory 910 is used to store computer programs; and the processor 920 is used to execute the programs stored in the memory 910 to implement the methods in the various embodiments of this application.

[0179] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0180] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0181] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0182] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0183] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

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

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

[0188] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for authenticating a vehicle, characterized in that, The vehicle controller applied to the vehicle includes: Send an authentication request to the module to be authenticated, and receive the encrypted message returned by the module to be authenticated; Based on the verification information, the first vehicle identification code and key stored in the vehicle controller, the encrypted message is authenticated to obtain an authentication result. The verification information is generated by the vehicle controller in response to the vehicle's start command, and the authentication result is used to characterize whether the module to be authenticated has passed the authentication. The authentication result is returned to the module to be authenticated.

2. The method according to claim 1, characterized in that, Before receiving the encrypted message returned by the module to be authenticated, the method further includes: Send the first vehicle identification code to the electrical inspection equipment; The device receives the key returned by the electronic inspection device, wherein the key is received from the cloud after the electronic inspection device sends the first vehicle identification code to the cloud.

3. The method according to claim 1, characterized in that, Before receiving the encrypted message returned by the module to be authenticated, the method further includes: Receive registration requests sent by diagnostic devices; The diagnostic device is verified based on the registration request; If the diagnostic device passes verification, the first vehicle identification code sent by the diagnostic device is received and stored.

4. The method according to any one of claims 1 to 3, characterized in that, Based on the verification information, the first vehicle identification code and key stored in the vehicle controller, the encrypted message is authenticated to obtain the authentication result, including: Based on the key and the verification information, the encrypted message is decrypted to obtain the second vehicle identification code; The authentication result is obtained based on the second vehicle identification code and the first vehicle identification code; Preferably, the authentication result is obtained based on the second vehicle identification number and the first vehicle identification number, including: If the second vehicle identification code and the first vehicle identification code are consistent, the authentication result indicates that the module to be authenticated has passed the authentication. If the second vehicle identification code and the first vehicle identification code are inconsistent, the authentication result indicates that the module to be authenticated has failed authentication.

5. The method according to any one of claims 1 to 3, characterized in that, After authenticating the encrypted message based on verification information, the first vehicle identification code and key stored in the vehicle controller, and obtaining the authentication result, the method further includes: If the authentication result indicates that the module to be authenticated has failed authentication, the connection with the module to be authenticated is disconnected and a security message is generated; The security message is sent to the display device.

6. A method for authenticating a vehicle, characterized in that, The authentication module applied to the vehicle includes: Receive authentication requests sent by the vehicle controller and obtain verification information from the authentication requests; Based on the verification information, the first vehicle identification code and key stored in the module to be authenticated, an encrypted message is generated, wherein the vehicle controller is deployed in the vehicle, and the encrypted message is used to authenticate the module to be authenticated through the vehicle controller; The encrypted message is sent to the vehicle controller, and the authentication result returned by the vehicle controller is received. The authentication result is used to indicate whether the module to be authenticated has passed the authentication.

7. A vehicle authentication system, characterized in that, include: An authentication module, deployed in the vehicle, is used to receive authentication requests sent by the vehicle controller, obtain verification information from the authentication requests, generate an encrypted message based on the verification information, the first vehicle identification code and key stored in the authentication module, send the encrypted message to the vehicle controller, and receive the authentication result returned by the vehicle controller. The encrypted message is used to authenticate the authentication module through the vehicle controller, and the authentication result is used to indicate whether the authentication module has passed the authentication. A vehicle controller, deployed in a vehicle, is used to send an authentication request to a module to be authenticated and receive an encrypted message returned by the module to be authenticated. Based on the verification information, the first vehicle identification code and key stored in the vehicle controller, the vehicle controller authenticates the encrypted message to obtain the authentication result and returns the authentication result to the module to be authenticated. The verification information is generated by the vehicle controller in response to the vehicle's start command.

8. The system according to claim 7, characterized in that, The system also includes: The diagnostic device is used to establish a connection with the vehicle controller, generate a registration request based on the private key stored in the diagnostic device, send the registration request to the vehicle controller, receive the verification result returned by the vehicle controller, and write the first vehicle identification code into the module to be authenticated and the vehicle controller if the verification result indicates that the vehicle controller has passed the verification. Preferably, the system further includes: The electrical testing equipment is used to establish a connection with the vehicle controller, read the first vehicle identification code, generate a key request based on the first vehicle identification code, send the key request to the cloud, receive the key returned by the cloud, and inject the key into the module to be authenticated and the vehicle controller.

9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 6.

Images