Vehicle-mounted secret key processing control method and system and electronic equipment

Abstract

The invention provides a vehicle-mounted secret key processing control method and system and electronic equipment, and relates to the field of vehicle communication control, the method can perform randomness check on a secret key through a secret key initialization step to ensure that the secret key has a high entropy value, so that the problem of insufficient randomness of the secret key is solved; in addition, according to the method, the validity of the original key can be judged through the key generation step, so that the problem of poor reliability in the key storage and reading process is solved; according to the method, the synchronous counter corresponding to the SecOC module can be emptied through the secret key updating step, replay attack is avoided, and therefore the safety of the secret key updating and synchronizing process is improved; according to the method, standardized operation can be carried out on the production and after-sales links of the vehicle through the key processing step, and the compatibility of use scenes is improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle communication control, and in particular to an on-board key processing control method, system, and electronic device. Background Technology

[0002] SecOC (Secure Onboard Communication) is a core module in the AUTOSAR architecture for vehicular communication security. Through encryption, authentication, and freshness management mechanisms, it addresses security issues in traditional vehicular networks (such as CAN bus), including plaintext transmission, lack of authentication leading to forgery, and replay attacks. While SecOC significantly improves vehicular communication security, it still faces numerous challenges in real-world scenarios, including insufficient key randomness, poor reliability of key storage and retrieval, low security of key updates and synchronization, and poor compatibility. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide an in-vehicle key processing control method, system, and electronic device. This method can perform a randomness check on the key during the key initialization step to ensure the key has a high entropy value, thereby solving the problem of insufficient key randomness. Furthermore, this method can determine the validity of the original key during the key generation step, thereby solving the problem of poor reliability during key storage and retrieval. This method can clear the synchronization counter corresponding to the SecOC module during the key update step to avoid replay attacks, thereby improving the security of the key update and synchronization process. This method can standardize operations in the vehicle's production and after-sales processes through the key processing step, improving the compatibility of usage scenarios.

[0004] In a first aspect, embodiments of the present invention provide a vehicle-mounted key processing control method, the method comprising: Key initialization steps: Generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU; Key generation steps: The communication encryption module corresponding to the vehicle ECU retrieves the original key corresponding to the vehicle identification code from the NVM memory, and uses the vehicle identification code to generate the authentication key corresponding to the original key; Key update steps: When the vehicle identification code is detected to be written to the vehicle ECU, the original key in the NVM memory is updated to the authentication key; Key processing steps: Control the vehicle ECU to process the vehicle identification code and its corresponding authentication key.

[0005] Optionally, the key generation step includes: Obtain the vehicle type corresponding to the vehicle identification code, and use the vehicle type to determine the key length and its corresponding multiple unit bytes of the original key; Generate random numbers corresponding to each byte based on the key length, and then generate the original key based on the random numbers; Determine if all random numbers in the unit byte are the same; if so, regenerate random numbers until all random numbers are different; if not, write and save the original key to the NVM memory corresponding to the vehicle ECU.

[0006] Optionally, the original key is written to and saved to the NVM memory corresponding to the vehicle ECU, including: Obtain the NVM memory corresponding to the vehicle ECU, determine the preset storage address area in the NVM memory, and initialize the storage address area using the preset initial values; Control the writing and saving of the original key to the storage address area; wherein the original key data in the storage address area is not erased when the NVM memory is updated.

[0007] Optionally, the key generation step includes: Initialize and obtain the board-side communication encryption module and key management module corresponding to the vehicle ECU; The control key management module retrieves the original key corresponding to the vehicle identification code from the NVM memory and determines whether the original key is the initial value. If the original key is not the initial value, then the authentication key is generated using the vehicle identification number and the original key; After the control board-side communication encryption module sends a key reading command to the key management module, it monitors the response result of the key management module in real time. After encrypting and transmitting the response result using the synchronization counter corresponding to the board-side communication encryption module, the authentication key is obtained based on the response result.

[0008] Optional key update steps include: After initializing the vehicle ECU, determine whether the vehicle identification code has been written to the vehicle ECU; If so, obtain the key value corresponding to the authentication key and determine whether the key value has changed; If the key value has not changed, the synchronization counter is cleared and the original key in the NVM memory is updated to the authentication key.

[0009] Optionally, the method further includes: If the key value changes, the HSM memory corresponding to the vehicle ECU is retrieved, and the authentication key is updated in the HSM memory.

[0010] Optional key processing steps include: When a vehicle is in the production stage, identify any abnormal data during the production process. The vehicle identification code and its corresponding abnormal data are used to generate a write command for the vehicle ECU, and the vehicle identification code is written to the vehicle ECU using the write command. After the vehicle ECU restarts, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

[0011] Optional key processing steps include: When a vehicle is in the after-sales stage, determine the repair data of the vehicle during the after-sales process; The vehicle identification code and its corresponding maintenance data are used to generate a write command for the vehicle ECU. After clearing the synchronization counter, the vehicle identification code is written to the vehicle ECU using the write command. After the vehicle ECU restarts, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

[0012] Secondly, the present invention provides an in-vehicle key processing and control system, the system comprising: Key initialization module: used to generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU; Key generation module: Used to control the communication encryption module corresponding to the vehicle ECU to obtain the original key corresponding to the vehicle identification code from the NVM memory, and use the vehicle identification code to generate the authentication key corresponding to the original key; Key update module: used to update the original key in the NVM memory to the authentication key when the vehicle identification code is detected to be written to the vehicle ECU; Key processing module: Used to control the vehicle ECU to process the vehicle identification code and its corresponding authentication key.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, which includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, and the processor executing the computer-executable instructions to implement the steps of the vehicle key processing control method provided in the first aspect.

[0014] Fourthly, embodiments of the present invention also provide a storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the steps of the vehicle key processing control method provided in the first aspect.

[0015] This invention provides a vehicle-mounted key processing control method, system, and electronic device. In processing SecOC-related keys, the method first generates an original key based on the vehicle identification code (VOC) and saves it to the NVM memory corresponding to the vehicle's ECU. Then, it controls the communication encryption module corresponding to the vehicle ECU to retrieve the original key corresponding to the VOC from the NVM memory and uses the VOC to generate an authentication key corresponding to the original key. When the VOC is detected being written to the vehicle ECU, the original key in the NVM memory is updated to the authentication key, and finally, the vehicle ECU is controlled to process the VOC and its corresponding authentication key. This method can solve the problem of insufficient key randomness by performing a randomness check on the key during key initialization, ensuring the key has a high entropy value. Furthermore, it can solve the problem of poor reliability during key storage and retrieval by judging the validity of the original key during key generation. The method can also improve the security of key update and synchronization processes by clearing the synchronization counter corresponding to the SecOC module during key update, preventing replay attacks. Finally, the method can standardize operations in vehicle production and after-sales processes through key processing steps, improving compatibility with various usage scenarios.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart of an in-vehicle key processing control method provided in an embodiment of the present invention; Figure 2 A flowchart of the key generation step S101 of an in-vehicle key processing control method provided in an embodiment of the present invention; Figure 3A flowchart illustrating the process of writing and saving the original key to the NVM memory corresponding to the vehicle ECU in an embodiment of the present invention. Figure 4 A flowchart of the key generation step S102 of an in-vehicle key processing control method provided in an embodiment of the present invention; Figure 5 A flowchart of key update step S103 of an in-vehicle key processing and control method provided in an embodiment of the present invention; Figure 6 A flowchart of key processing step S104 of an in-vehicle key processing control method provided in an embodiment of the present invention; Figure 7 A flowchart of key processing step S104 of another vehicle key processing control method provided in an embodiment of the present invention; Figure 8 This is a key reading timing diagram corresponding to a vehicle-mounted key processing and control method provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the authentication key update process corresponding to an in-vehicle key processing and control method provided in an embodiment of the present invention; Figure 10 This is a key conversion diagram corresponding to an in-vehicle key processing and control method provided in an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of an in-vehicle key processing and control system provided in an embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0020] icon: 1110 - Key initialization module; 1120 - Key generation module; 1130 - Key update module; 1140 - Key processing module; 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] Specifically, the implementation of SecOC technology mainly includes the following aspects: 1) Encryption and authentication mechanisms.

[0023] Data encryption: Use symmetric encryption (such as AES-128) or asymmetric encryption (such as RSA-2048) to encrypt transmitted data to prevent data leakage.

[0024] Message Authentication Code (MAC): Generates a signature (such as HMAC-SHA256) based on a key to verify data integrity and authenticity. MAC calculation typically includes a Data Identifier (DataID), the original data (Authentic I-PDU), and a Freshness Value (FV).

[0025] The digital signature process mainly occurs in asymmetric encryption scenarios, where the sender uses a private key to sign and the receiver uses a public key to verify the signature, ensuring the reliability of the data source.

[0026] 2) Freshness management.

[0027] Dynamic counters: FV is generated based on the Trip Counter, Reset Counter, and Message Counter to prevent replay attacks.

[0028] Synchronization mechanism: The master node (such as a gateway) distributes FV update information to the slave nodes through synchronization messages to ensure FV consistency between the sender and receiver. For example, the Trip Counter increments on each power-on, and the Reset Counter increments periodically.

[0029] 3) Key management.

[0030] Key generation: High-strength random number generation algorithms (such as Elliptic Curve Cryptography (ECC)) are used to ensure key unpredictability.

[0031] Key storage: The key is stored in a hardware security module (HSM) or NVM (non-volatile memory). The HSM provides physical protection to prevent brute-force attacks.

[0032] Key distribution and update: The initial key is pre-loaded into the ECU through a secure channel; during the update, the new key is transmitted through an SSL / TLS encrypted channel to avoid man-in-the-middle attacks.

[0033] 4) Message structure and processing flow.

[0034] Secure I-PDU: Consists of a header, raw data, and truncated FV and MAC. For example, the FV is truncated by the least significant byte, and the MAC is truncated by the most significant 3 bytes to balance security and bandwidth.

[0035] Sending process: Add FV and MAC, construct a secure message and send it.

[0036] Receiver process: parse the message, reconstruct the complete FV, verify MAC consistency, and update the local FV state.

[0037] 5) Application scenario support.

[0038] V2X communication: Protects data such as speed and driving intentions exchanged between vehicles (V2V) and between vehicles and infrastructure (V2I).

[0039] ADAS system: Ensures the safety of sensor data (such as cameras and radar) and control signals (such as automatic emergency braking).

[0040] Remote diagnostics and OTA updates: Encrypt diagnostic data and firmware update packages to prevent tampering or theft.

[0041] While SecOC significantly improves the security of in-vehicle communications, it still faces the following technical challenges and limitations: 1) Performance and real-time performance are contradictory.

[0042] Computational burden: Encryption, decryption, and MAC generation consume ECU computing resources, which may affect real-time performance. For example, the CAN bus message payload is only 8-64 bytes, but the load rate increases after adding MAC and FV, resulting in communication delays.

[0043] Resource consumption: MCU computing power and storage space are limited, and security mechanisms may consume too many resources, affecting the normal operation of other functions.

[0044] 2) Key management complexity.

[0045] Key sharing risk: Symmetric encryption requires a shared key. If the key is transmitted in plaintext, it is easily stolen. Some MCUs lack a secure storage environment, storing the key in plaintext in memory, which poses a risk of leakage.

[0046] Key consistency after component replacement: When replacing the ECU, it is necessary to ensure that the new key is consistent with the old key, otherwise communication may fail.

[0047] Certificate management challenges: When enabling HSM (Hardware Security Module), a security certificate must be installed in advance. After replacing the component, the certificate must be kept consistent, otherwise authentication will fail.

[0048] 3) Freshness management loopholes.

[0049] Synchronization risk: If the master node's synchronization message is lost or delayed, the slave node's FV may fail, resulting in the dropping of legitimate messages (such as in a DoS attack).

[0050] Counter overflow: The message counter (MsgCnt) maintains its maximum value after reaching it, which may be exploited by attackers to replay old messages.

[0051] 4) Security configuration complexity.

[0052] Incorrect parameter configuration: SecOC requires configuration of parameters such as encryption algorithm, key length, and FV update frequency. Improper configuration may reduce security. For example, an FV update frequency that is too low makes the system vulnerable to replay attacks, while one that is too high increases the computational burden.

[0053] Protocol compatibility: SecOC needs to be adapted to different bus protocols such as CAN, LIN, and Ethernet, which is quite complex.

[0054] 5) Attack surface expansion.

[0055] Design flaws can be exploited: For example, when using SecOC to authenticate complete payload information on SOME / IP-TP, design flaws may lead to DoS attacks.

[0056] Side-channel attack: By analyzing side-channel information such as the power consumption and electromagnetic radiation of the encryption module, it is possible to deduce the key or sensitive data.

[0057] 6) Industrial ecosystem limitations.

[0058] Insufficient self-reliance and controllability: We still rely on imports for core encryption algorithms (such as ECC) and HSM (Hardware Security Module) hardware, which poses a supply chain security risk.

[0059] Inconsistent standards: Different automakers and suppliers have different implementations of SecOC, resulting in poor interoperability and increased integration costs.

[0060] In summary, existing SecOC technologies still suffer from numerous problems, including insufficient key randomness, poor reliability in key storage and retrieval, low security in key update and synchronization processes, and poor compatibility. Based on this, this invention discloses an in-vehicle key processing control method, system, and electronic device. This method solves the problem of insufficient key randomness by performing a randomness check on the key during key initialization to ensure the key has a high entropy value. Furthermore, the method solves the problem of poor reliability in key storage and retrieval by judging the validity of the original key during key generation. The method also improves the security of key update and synchronization processes by clearing the synchronization counter corresponding to the SecOC module during the key update step to prevent replay attacks. Finally, the method enables standardized operations in vehicle production and after-sales processes through key processing steps, improving compatibility with various application scenarios.

[0061] To facilitate understanding of this embodiment, a vehicle-mounted key processing and control method disclosed in this embodiment of the invention will first be introduced, such as... Figure 1 As shown, the method includes: Key initialization step S101: Generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU.

[0062] The core operation of this step is to generate an initial raw key based on the vehicle's unique identifier, the Vehicle Identification Number (VIN), using a preset security algorithm. This raw key is then permanently stored in the non-volatile memory (NVM) corresponding to the vehicle's Electronic Control Unit (ECU). Since the VIN is a unique identification code for each vehicle (like a vehicle ID card), generating the raw key based on the VIN ensures the key's vehicle-specific attribute, preventing different vehicles from reusing the same key. Furthermore, the non-volatile nature of the NVM (data is not lost after power failure) ensures that the raw key can still be stably read after the ECU is powered off and restarted, providing a reliable initial data foundation for subsequent key generation.

[0063] Key generation step S102: The communication encryption module corresponding to the vehicle ECU obtains the original key corresponding to the vehicle identification code from the NVM memory, and uses the vehicle identification code to generate the authentication key corresponding to the original key.

[0064] Through relevant instructions, the communication encryption module (typically deeply associated with the SecOC module in the AUTOSAR architecture), responsible for communication security within the vehicle's ECU, retrieves the original key corresponding to the current vehicle's VIN from the NVM memory. Then, using the VIN as the association factor again, a more secure authentication key is generated from the original key through a specific key derivation algorithm (such as hash-based or symmetric encryption-based derivation logic). The core of this step is secondary enhanced binding; by having the VIN participate in authentication key generation again, the authentication key is further ensured to be strongly associated with the current vehicle's identity, preventing the original key from being stolen and misused in other vehicles. Simultaneously, the communication encryption module, as the secure execution carrier for key generation, prevents data from flowing through insecure areas within the ECU during the key generation process, reducing the risk of key leakage.

[0065] Key update step S103: When the vehicle identification code is detected to be written to the vehicle ECU, the original key in the NVM memory is updated to the authentication key.

[0066] The system monitors the VIN writing status of the vehicle ECU in real time (such as the first VIN writing during vehicle production, rewriting the VIN after ECU replacement, etc.). When the VIN is successfully written to the ECU, the key update mechanism is immediately triggered: the original key stored in the NVM memory is replaced with the authentication key generated in step S102.

[0067] VIN writing is a crucial step in binding vehicle identity with the ECU. Updating the key at this point ensures consistency between the key, ECU, and VIN, preventing key mismatch issues caused by ECU replacement or VIN rewriting (such as the old key not being compatible with the communication requirements of the new VIN). Furthermore, in conjunction with the original context, this step also simultaneously clears the synchronization counter (a core component for freshness management) corresponding to the SecOC module, effectively preventing attackers from replaying historical messages using the freshness value (FV) of the old counter, further enhancing communication security after the key update.

[0068] Key processing step S104: Control the vehicle ECU to perform key processing on the vehicle identification code and its corresponding authentication key.

[0069] After the key update is complete, the control ECU executes a standardized key processing procedure for the current vehicle's VIN and its corresponding authentication key, ensuring that the key is compatible with the various security functions of the SecOC module. This key processing includes three main categories of operations: first, security verification (verifying whether the authentication key has been tampered with and whether it matches the VIN); second, module association configuration (binding the authentication key to the SecOC's encryption module, MAC generation module, and freshness management module to ensure that the key can be used for data encryption and authentication in subsequent communications); and third, protocol adaptation (configuring the usage rules of the authentication key according to the actual bus protocol used by the vehicle (such as CAN, Ethernet), such as encryption algorithm matching and key length adaptation). The core value of this step is to standardize key operations throughout the entire production-after-sales process, solve compatibility issues between ECUs from different suppliers, and reduce integration costs.

[0070] Optionally, the key generation step S101, as follows: Figure 2 As shown, it includes: Step S201: Obtain the vehicle type corresponding to the vehicle identification code, and use the vehicle type to determine the key length and its corresponding multiple unit bytes corresponding to the original key.

[0071] First, obtain the vehicle type information (such as vehicle type, functional level, etc.) contained in the current Vehicle Identification Number (VIN). Then, based on the security requirements corresponding to the vehicle type (such as high-end models or vehicles involving autonomous driving functions having higher security levels), determine the length of the original key (such as 128 bits, 256 bits, etc.) and split the key length into multiple unit bytes (for example, a 128-bit key corresponds to 16 unit bytes, and each unit byte is 8 bits).

[0072] Step S202: Generate random numbers corresponding to unit bytes sequentially based on the key length, and generate the original key based on the random numbers.

[0073] Using the key length determined in step S201 as the total range, generate corresponding random numbers byte by byte. Concatenate all the random numbers in sequence to form the complete original key. Random number generation relies on a cryptographically secure random number generator (such as a hardware noise-based true random number generator) to ensure that the random number of each byte is unpredictable. By generating and concatenating the random numbers sequentially, the overall structure of the original key is guaranteed to conform to the preset length, providing a standardized key format for subsequent encryption and authentication operations.

[0074] Step S203: Determine whether all random numbers in the unit byte are the same; if so, regenerate random numbers until all random numbers are different; if not, write the original key to the NVM memory corresponding to the vehicle ECU.

[0075] A repeatability check is performed on all unit-byte random numbers generated in step S202. If all unit bytes are identical, a regeneration process is triggered (repeating step S202) until all unit-byte random numbers differ (i.e., all random numbers are different). At this point, the original key is written to and permanently stored in the vehicle ECU's NVM memory. In a real-world scenario, after generating the original key Key_raw (Key_raw is a 16-byte random number), the randomness of the generated Key_raw needs to be checked. If all bytes of the key are identical (e.g., all 16 bytes are 0x00), the original key needs to be regenerated. If they are different, the original key generation was successful.

[0076] In existing technologies, if all bytes are identical during key generation (e.g., all 0x00), attackers can easily crack encrypted communication, leading to data leakage or tampering. However, the key generation step S101 of this method checks for randomness during key generation; if the condition is not met (e.g., all bytes are identical), the key is regenerated, ensuring that the key has a high entropy value.

[0077] Subsequently, the Key_raw can be written to the ECU's NVM (Non-volatile Memory) for storage through relevant secure channels. If a supplier is involved, the original Key_raw can be sent to the supplier, who will then write the received Key_raw to the ECU's NVM. Optionally, the original key can be written to and saved to the NVM memory corresponding to the vehicle ECU, such as... Figure 3 As shown, it includes: Step S301: Obtain the NVM memory corresponding to the vehicle ECU, determine the preset storage address area in the NVM memory, and initialize the storage address area using the preset initial value.

[0078] First, locate the NVM memory corresponding to the current vehicle ECU (this needs to be confirmed through the ECU hardware identifier or communication protocol to avoid accidentally operating the NVM of other ECUs); from the NVM's preset configuration, determine the secure storage address area specifically used to store the original key (this area is usually a pre-divided independent block, isolated from the ECU's ordinary data storage area); then, use preset initial values ​​(such as all 0x00, all 0xFF, or specific encrypted padding values) to perform a complete overwrite initialization of this storage address area, clearing any historical data or invalid information that may remain in the area.

[0079] The division of the preset storage address area has strong security. It is usually fixed in the ECU hardware design stage and is only open to the SecOC module or the control unit with the highest security privileges. Ordinary applications cannot read or modify it, thus preventing the key storage location from being accessed by unauthorized users. The core purpose of initialization is to clear the data. If old keys, test data, or other information remain in the storage area, the newly written original key may be contaminated (e.g., data overlay), or attackers may infer the key format through the residual information. Therefore, it is necessary to ensure the thoroughness of initialization by covering the entire area.

[0080] Step S302: Control the original key to be written and saved to the storage address area; wherein the original key data in the storage address area will not be erased when the NVM memory is updated.

[0081] After the storage area is initialized, the original key (Key_raw) is completely written into the initialized secure storage address area through the ECU's secure communication link (such as an encrypted diagnostic protocol or a SecOC dedicated control channel). At the same time, through the NVM's hardware configuration or software permission settings, anti-erasure protection is enabled for this storage area. This means that when the NVM performs regular data updates (such as ECU firmware upgrades or ordinary parameter modifications), it will automatically skip this area and will not erase, overwrite, or modify the original key stored therein.

[0082] Secure write links are a critical protection. If keys are transmitted through plaintext links, they may be intercepted during the write process. Therefore, encrypted channels are needed to ensure that the transmission of keys from the sending end (such as production servers or vendor configuration devices) to the NVM storage area is kept confidential throughout the entire process. The necessity of anti-erasure protection: The original key is the basis for generating the authentication key and supporting the SecOC encryption / authentication function. If it is accidentally erased due to routine ECU updates (such as OTA upgrades or after-sales parameter adjustments), the entire SecOC module will fail (unable to generate legitimate authentication information), which will lead to the interruption of vehicle communication. Therefore, it is necessary to ensure its long-term stable storage through hardware or permission locking.

[0083] After writing, integrity verification is usually required (such as calculating the CRC check value or hash value of the key and comparing it with the written data) to confirm that the original key has no lost packets or errors, and to ensure the accuracy of the stored data.

[0084] In specific scenarios, the key storage function can be triggered when it is necessary to store the Key_raw. The Key_raw data needs to be stored in the NVM. A fixed key storage address area (16 bytes) should be provided to store the Key_raw key data, and the initial value of the data in the key storage area should be set to all 0xFF. The location on the NVM where the Key_raw key is stored should not be overwritten or erased due to system / software updates. When storing a new key, the old key should be overwritten. Furthermore, when the SecOC module is running, the Key_auth generated using the new Key_raw key should be provided to the SecOC module.

[0085] In existing technologies, keys stored in NVM (Non-Volatile Memory) may be overwritten during system updates, or misjudged by security modules during reading due to unprocessed initial values. This method, however, fixes the key storage address area and sets the initial value to all 0xFF to avoid confusion with valid keys. Before reading, it checks if the key is the initial value; if so, it returns an error to prevent the use of uninitialized keys. When storing a new key, it overwrites the old key, ensuring key version consistency.

[0086] Optionally, the key generation step S102, such as Figure 4 As shown, it includes: Step S401: Initialize and obtain the board-side communication encryption module and key management module corresponding to the vehicle ECU.

[0087] First, the two core security modules within the vehicle's ECU are initialized: one is the board-side communication encryption module (i.e., the SecOC module in the AUTOSAR architecture, which is responsible for the encryption and authentication of subsequent communication data), and the other is the key management module (KeyManagement, which is specifically responsible for key storage, retrieval, validity verification, and secure distribution). After initialization, a communication link between the two modules is established through the ECU's internal security control bus to ensure secure data exchange during subsequent operations.

[0088] The core purpose of module initialization is to clear the state and activate the function. It is necessary to clear the residual historical key data and error markers in the two modules, and load the preset security algorithm (such as HMAC-SHA256, AES-128) to ensure that the module has key processing capability. Establishing a dedicated communication link is to avoid the key data from flowing through non-secure channels inside the ECU (such as ordinary data bus), thereby reducing the risk of interception or tampering.

[0089] Step S402: The control key management module retrieves the original key corresponding to the vehicle identification code from the NVM memory and determines whether the original key is the initial value.

[0090] This step controls the initialized key management module to read the raw key (Key_raw) bound to the current vehicle VIN through the preset security address of the NVM memory (i.e., the key storage area determined in step S301); after reading, the raw key is immediately checked for initial value to determine whether it is the default value when the NVM is initialized (such as all 0x00, all 0xFF or the preset invalid placeholder).

[0091] Initial value verification is a critical security threshold. If the original key is still the initial value, it means that NVM has not written the key correctly (such as missing or failing to write during the production stage). If the authentication key is generated directly at this time, subsequent communication will not have a valid key available, resulting in a security vulnerability. Verification can detect key storage anomalies in advance and prevent invalid keys from flowing into subsequent processes.

[0092] Step S403: If the original key is not the initial value, then use the vehicle identification number and the original key to generate an authentication key.

[0093] If the verification result of step S402 is that the original key is not the initial value (i.e. the key is valid), then the key derivation process is started. The vehicle VIN (as a unique identification factor) and the original key (as the base key) are input into the preset cryptographic derivation algorithm (such as the HMAC-based key derivation function HKDF, or AES-Based Key Derivation Function). The algorithm calculates and generates an authentication key (Key_auth) with higher security.

[0094] The core of this step is dual-factor binding. The addition of the VIN ensures that the authentication key is strongly associated with the current vehicle (even if the original key is accidentally leaked, the attacker cannot generate a valid authentication key without the corresponding VIN); while using a standard cryptographic derivation algorithm can guarantee that the entropy (randomness) of the authentication key is not lower than that of the original key, and at the same time adapt to the encryption / authentication requirements of the SecOC module (such as key length matching the algorithm).

[0095] In step S404, after the control board-side communication encryption module sends a key reading command to the key management module, it monitors the response result of the key management module in real time.

[0096] The control board-side communication encryption module (SecOC) sends an authentication key read command to the key management module (Key Management) (the command must carry the identity identifier of the SecOC module to prevent unauthorized modules from calling it); after the command is sent, the SecOC module enters a real-time listening state and continuously monitors the response results of Key Management, including whether the response timed out, whether the response message is complete, and whether it carries an error code (such as key not generated, insufficient permissions), etc.

[0097] Identity identification and real-time monitoring are designed to address the risks of module spoofing and communication packet loss. If a malicious module impersonates SecOC and sends a read command, Key Management can reject it through identity identification. Monitoring the response results can promptly detect communication anomalies (such as command loss due to bus interference) and trigger a retry mechanism (such as resending the read command) to ensure that the authentication key can be successfully retrieved.

[0098] Step S405: After encrypting and transmitting the response result based on the synchronization counter corresponding to the board-side communication encryption module, obtain the authentication key based on the response result.

[0099] When the Key Management module returns a response (including authentication key data), the SecOC (Secondary Authentication and Coding) module first calls its own synchronization counter (i.e., the Trip Counter in SecOC Freshness Management, which records the freshness value FV of the current communication). Using the current value of the synchronization counter as a dynamic factor, the response (including the authentication key) is encrypted (e.g., using the AES-GCM algorithm, with FV as additional authentication data AAD) to achieve secure data transmission. After transmission, the SecOC module decrypts the response, extracts and verifies the integrity of the authentication key (e.g., by comparing the key hash value), and completes the acquisition of the authentication key after confirming that it is correct.

[0100] The synchronization counter is added to prevent replay attacks. Even if an attacker intercepts the response (including the authentication key), the SecOC module will refuse to receive it the next time the response is replayed because the synchronization counter value is different for each communication. Encrypted transmission and integrity verification can ensure that the authentication key is not leaked or tampered with when it is transferred between modules, ultimately providing the SecOC module with a usable and secure key.

[0101] The above process can be referenced. Figure 8 As shown, when the Key_raw needs to be read from NVM for use by the SecOC module, the key reading function is triggered. Before reading, it is necessary to check whether the key data is an initial value (all 0xFF). If it is an initial value, an error should be returned to the SecOC module, indicating that the key is unavailable. If it is not an initial value, the Key_raw data is read. VIN data needs to be written to the ECU implementing the SecOC mechanism, and it needs to be ensured that the VIN data is not overwritten by other data. If the VIN is an initial value, an error should be returned to the SecOC module, indicating that the VIN is unavailable. If it is not an initial value, the VIN data is read.

[0102] The key conversion process can be found in the following reference. Figure 10 As shown, the Key_raw is processed by the Algorithm_Chery to obtain the authentication key Key_auth (16 bytes), which can be provided to the SecOC module.

[0103] For ECUs with the Hardware Security Module (HSM) enabled, it is not necessary to read the Key_auth; the SecOC module does not work when VIN is at its initial value.

[0104] Optionally, the key update step S103, such as Figure 5 As shown, it includes: Step S501: After initializing the vehicle ECU, determine whether the vehicle identification code has been written to the vehicle ECU.

[0105] First, the vehicle ECU is initialized (e.g., clearing the ECU temporary cache, activating the internal security detection module, and establishing a communication link with the key management module). After initialization, the vehicle identification number (VIN) is checked through the ECU's identity recognition interface or data reading module to see if it has been successfully written to the ECU. The criteria for judgment are whether the VIN is complete, whether the format conforms to the preset specifications (e.g., 17-bit character encoding), and whether it matches the actual vehicle identity.

[0106] The purpose of ECU initialization is to reset the security state and prevent historical residual data from interfering with VIN verification. The VIN is the identity anchor for key updates. Only when the VIN is successfully written can the subsequent updated key be strongly bound to the current vehicle, preventing key mismatch (such as updating the key of vehicle A to the ECU of vehicle B). If a VIN is detected as not being written or being written abnormally (such as an incorrect format), the key update process is paused, triggering VIN rewriting or fault diagnosis.

[0107] Step S502: If yes, obtain the key value corresponding to the authentication key and determine whether the key value has changed.

[0108] If step S501 detects that the VIN has been successfully written, the authentication key (Key_auth) generated in step S102 is retrieved through the key management module of the ECU, and its specific key value (such as 128-bit binary data or the corresponding hexadecimal string) is obtained; the current authentication key value is compared with the historical authentication key baseline value temporarily stored in the ECU (usually the hash value of the previously generated authentication key) to determine whether the key value has changed.

[0109] Historical authentication key baseline values ​​are typically stored in hash form (such as SHA-256 hash) rather than in plaintext. This avoids leakage of the baseline value and allows for quick determination of whether the current key has been tampered with or has derivation anomalies through hash comparison. Determining whether the key value has changed is crucial for choosing between a regular update or a high-security update strategy: if it has not changed, it means the key is still validly derived from the current VIN and can be updated to the NVM in a regular manner; if it has changed, it is necessary to be wary of key anomalies (such as VIN replacement or derivation algorithm failure) and to protect it with a more secure storage medium (HSM).

[0110] In step S503, if the key value has not changed, the synchronization counter is cleared and the original key in the NVM memory is updated to the authentication key.

[0111] If the comparison result in step S502 is that the authentication key value has not changed (i.e., the key derivation is normal and matches the current VIN), the synchronization counter clearing operation of the board-side communication encryption module (SecOC) is first triggered. The historical values ​​of the synchronization counters (such as Trip Counter and Message Counter) used for fresh value (FV) management in SecOC are cleared, and the counters are reset to the initial security value (such as 0 or the preset starting value). Subsequently, through the secure write channel of the ECU, the original key (Key_raw) stored in the NVM memory is overwritten and updated to the current authentication key (Key_auth), while retaining the erasure protection configuration of the NVM storage area.

[0112] Clearing the synchronization counter is to prevent replay attacks. The historical value of the old counter may be intercepted by attackers and used to forge the fresh value (FV). After resetting, the new counter starts to increment from the initial value, ensuring that the FV of subsequent communications are all dynamic new values, and avoiding the replay of old messages. The core of overlaying and updating NVM is key upgrade. The authentication key (Key_auth) has an additional VIN derivation step compared to the original key (Key_raw), making it more secure. Replacing the original key with it for storage can improve the anti-attack capability of subsequent SecOC encryption / authentication. At the same time, anti-erasure protection is retained to ensure that the updated authentication key will not be accidentally lost due to routine NVM operations (such as firmware upgrades).

[0113] Optionally, the method further includes: if the key value changes, obtaining the HSM memory corresponding to the vehicle ECU and updating the authentication key to the HSM memory. If the comparison result of step S502 indicates that the authentication key value has changed (possible reasons: VIN rewriting, key derivation algorithm parameter adjustment, or accidental tampering with the original key), firstly, the hardware security module (HSM) memory associated with the current ECU is located and obtained through the ECU's hardware security interface; then, the changed authentication key is written to the HSM memory through the HSM's dedicated encrypted transmission channel (such as the hardware encryption bus between the HSM and the ECU), and the HSM's physical protection mechanism (such as anti-tamper detection and brute-force locking) is enabled.

[0114] HSM has a much higher security advantage than ordinary NVM. HSM has an independent encryption operation unit and a physically isolated storage area, which can resist side-channel attacks (such as power consumption analysis and electromagnetic radiation analysis) and physical disassembly attacks. When the key is stored in HSM, even if the ECU is cracked, the attacker cannot read the plaintext key.

[0115] The reason for choosing HSM to store the changed key is that key value changes may be accompanied by security risks (such as identity changes or potential tampering), and a higher level of security medium is needed to isolate the risks. At the same time, HSM can also directly participate in subsequent SecOC encryption / authentication operations (such as generating MAC and decrypting data), avoiding the key from being exported from HSM and further reducing the risk of leakage.

[0116] The above process can be referenced. Figure 9As shown, the Key_auth key is directly associated with the vehicle's VIN. Therefore, any VIN write operation (regardless of whether the newly written VIN is the same as the one already stored in the ECU) is considered a Key_auth key update. ECUs integrating the SecOC component need to be able to determine whether the Key_auth has been updated. When the Key_auth is updated, the NVM of the synchronization counter needs to be cleared. When the HSM (Hardware Security Module) is enabled, if the Key_auth value differs from the old value, the new Key_auth key must be updated in the HSM.

[0117] In existing technologies, when a vehicle's VIN is changed or an ECU is replaced, the key needs to be updated synchronously. However, traditional solutions lack standardized procedures, which can easily lead to communication interruptions or security failures. In contrast, the key update step S103 of this method treats the VIN write operation as a key update trigger condition, forcibly clearing the synchronization counter NVM (non-volatile memory) to prevent replay attacks. Furthermore, it utilizes an ECU with an enabled HSM (hardware security module) to directly update the key to the HSM, without exposing the key plaintext, thus improving security.

[0118] Key processing step S104 focuses on the vehicle production process. Through a closed-loop logic of anomaly detection, identity writing, and restart configuration, it ensures that the VIN and authentication key are securely bound during the production stage, laying the foundation for subsequent vehicle communication security. Optionally, key processing step S104, such as... Figure 6 As shown, it includes: Step S601: When the vehicle is in the production stage, identify abnormal data of the vehicle during the production process.

[0119] When a vehicle is in the production and assembly stage (such as ECU pre-installation and vehicle network debugging), the monitoring system on the production line (such as the production line MES system and ECU diagnostic tools) collects key data in real time during the vehicle production process (including VIN generation and verification data, original key writing status data, ECU module communication data, etc.). The collected data is verified for compliance and integrity, and abnormal data is screened and identified, that is, abnormal information that does not conform to the preset production specifications and may affect key processing.

[0120] Step S602: Generate a write command for the vehicle ECU using the vehicle identification code and its corresponding abnormal data, and write the vehicle identification code to the vehicle ECU using the write command.

[0121] After eliminating or repairing the abnormal data identified in step S601 (such as regenerating a compliant VIN or rewriting the original key), the compliant VIN and the abnormal data processing results (such as confirmation information that the VIN format has been corrected and the key is written normally) are used as inputs. The production line's security instruction generation tool generates a VIN writing instruction that the ECU can recognize (the instruction must contain identity authentication information to prevent unauthorized production line equipment from operating it incorrectly). The writing instruction is sent to the vehicle ECU through an encrypted diagnostic channel, controlling the ECU to write the VIN into the internal identity storage area (associated with the NVM key storage area).

[0122] Step S603: After the vehicle ECU restarts, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

[0123] After the VIN is written, a safe restart of the vehicle ECU is triggered via production line control commands (not a simple power-off restart, but requires clearing the ECU temporary cache and reinitializing all security modules); after the ECU restarts successfully, the already initialized communication encryption module (i.e., the SecOC module) is called to perform standardized key processing on the VIN and its corresponding authentication key (Key_auth) in the current ECU: Step 1: Binding Identity and Key; Associate and store the hash value of the VIN with the authentication key to ensure that only the key matching the VIN can be used in subsequent communications; Step 2: Key integrity verification; Calculate the hash value of the authentication key using the hash algorithm (such as SHA-256) built into the SecOC module, and compare it with the baseline hash value generated in step S102 to confirm that the key has not been tampered with. Step 3: Encryption parameter configuration; Based on the vehicle production specifications (such as bus type, security level), configure the corresponding encryption / authentication parameters for the authentication key (such as AES-128 encryption mode, HMAC-SHA256 authentication mode, synchronization counter increment frequency).

[0124] In real-world scenarios, the SecOC Key_raw key has already been pre-installed on the supplier's production line. On the production line, only the VIN needs to be written and the ECU restarted. When writing the VIN on the production line, the following four scenarios may occur: 1. New vehicles are brought into service. The ECU contains the default VIN. After the production line writes the VIN to the ECU and sends a restart command, the ECU will execute the Key_auth update process (e.g., ...). Figure 9 (as shown), and initialize the SecOC module.

[0125] 2. After the missing parts for the vehicle are manufactured, the ECU is re-uploaded. In the case of a single missing part (TBOX or FLZCU left front domain controller), after the missing part is re-uploaded, the VIN is written to the re-uploaded ECU and the ECU is restarted.

[0126] 3. After vehicle production is completed, if a problem is found, the system is restarted. If the TBOX has a problem, a new TBOX needs to be replaced, a VIN write operation needs to be performed on the TBOX, and a restart command needs to be sent to the TBOX. If the FLZCU has a problem, a new FLZCU needs to be replaced, a VIN write operation needs to be performed on the FLZCU, and a restart command needs to be sent to the FLZCU. If there is a SecOC-related DTC in the FLZCU (fault code: U1313-8, verification of synchronization message received from TBOX failed), the DTC needs to be cleared. 4. The VIN of car A will be updated to the VIN of car B. Please refer to the description of the new vehicle launch. It will not be repeated here.

[0127] The core objective of key processing step S104 in the vehicle after-sales process is to ensure that the VIN and authentication key remain strongly bound after after-sales operations, preventing vehicle communication security failures due to after-sales operations, through the logic of repair data confirmation, secure writing to the VIN, and key adaptation after restart, for scenarios such as repair and parts replacement (e.g., ECU replacement). Optionally, key processing step S104, such as... Figure 7 As shown, it includes: Step S701: When the vehicle is in the after-sales stage, determine the maintenance data of the vehicle during the after-sales process.

[0128] When a vehicle is in the after-sales process (such as 4S store repairs, ECU replacement, and vehicle system fault diagnosis), after-sales personnel use specialized diagnostic equipment (such as OBD diagnostic tools and the car manufacturer's after-sales cloud platform) to collect the vehicle's repair data during the after-sales process. The collected data is then categorized, organized, and its authenticity is verified to determine key repair information, which is directly related to the validity of subsequent VIN writing and key processing.

[0129] The repair data from after-sales scenarios differs significantly from the anomaly data from the production process, and the core discrepancies include three key types of information: Hardware change data: such as whether the ECU has been replaced (the hardware serial number and model of the new ECU must be recorded), whether the NVM / HSM memory has been repaired (the storage medium must be confirmed to be intact); Key status data: such as the backup status of the original key in the old ECU, whether the new ECU has a pre-written temporary key, and whether there are fault codes in the key management module (such as key reading failure). Communication anomaly data: such as whether there were SecOC authentication failures or synchronization counter overflows before after-sales repair, and whether the communication of the vehicle bus (such as CAN / Ethernet) returned to normal after repair. The core purpose of determining repair data is to adapt to the special characteristics of after-sales scenarios. For example, after replacing the ECU, the VIN needs to be re-bound, and the key needs to be regenerated after it is lost, so as to avoid directly applying the production process and causing operational failures.

[0130] Step S702: Use the vehicle identification code and its corresponding maintenance data to generate a write command for the vehicle ECU, and after clearing the synchronization counter, use the write command to write the vehicle identification code to the vehicle ECU.

[0131] First, based on the repair data determined in step S701, basic hardware / key faults are eliminated (such as replacing the faulty ECU or restoring the NVM storage function). Then, using the vehicle's original VIN (retrieved from the automaker's after-sales database to ensure it matches the vehicle chassis number) and the repair data confirmation results (such as the new ECU hardware being normal and the old key being backed up) as input, an ECU-specific VIN write command is generated through the after-sales diagnostic equipment (the command must carry the after-sales personnel's authorization certificate and equipment identity authentication information to prevent unauthorized repairs). Before sending the command, the ECU is first controlled through the diagnostic channel to clear the synchronization counters of the board-side communication encryption module (SecOC) (including Trip Counter and Message Counter to avoid residual values ​​of the old counters leading to subsequent replay attacks). Finally, the VIN write command is sent to the ECU through an encrypted diagnostic session to complete the writing of the VIN to the ECU's identity storage area.

[0132] Step S703: After the vehicle ECU restarts, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

[0133] After the VIN is written, the after-sales diagnostic equipment sends a secure restart command to the ECU. Upon restarting, the ECU automatically reinitializes all security modules (including the key management module and the SecOC module, clearing old configuration data from the temporary cache). After a successful restart, the ECU calls the already initialized communication encryption module (SecOC) to perform standardized key processing on the current VIN and its corresponding authentication key (Key_auth, which needs to be regenerated for a new ECU and restored from backup for an old ECU). This includes: Step 1: VIN and Repair Data Matching and Verification. Verify whether the currently written VIN is consistent with the original VIN in the after-sales database and whether it matches the hardware change record in the repair data (e.g., whether the new ECU model supports the key length corresponding to this VIN).

[0134] Step 2: Verification of the integrity and security of the authentication key. The hash value of the authentication key is calculated by the SecOC module and compared with the key hash value backed up in the after-sales database (to confirm that it has not been tampered with). At the same time, it is checked whether the key meets the current ECU's security storage requirements (such as whether it needs to be stored in the HSM).

[0135] Step 3: Key Adaptation Configuration for After-Sales Scenarios. Adjust key parameters based on repair data (e.g., after replacing the ECU, reconfigure the key's compatibility parameters with the new ECU hardware; after repairing communication faults, adjust the synchronization counter's increment frequency) to ensure the key is compatible with in-vehicle communication scenarios after after-sales repairs.

[0136] In real-world scenarios, when an ECU implementing the SecOC mechanism needs to have parts replaced, the following procedure should be followed: Replacement should be performed using a part of the same SecOC module version or a backward-compatible higher SecOC module version number to ensure consistent SecOC mechanism algorithms and configurations; after replacement, authorized personnel should sequentially refresh the VIN codes using a diagnostic tool; finally, an ECU restart command should be sent, causing the ECU to restart and initialize the SecOC module.

[0137] When replacing both the TBOX and FLZCU simultaneously, use a diagnostic tool to write the VIN into both the TBOX and FLZCU, and send a restart command to both. The TBOX and FLZCU should then update their respective SecOC keys and clear the synchronization counter values. If there are any SecOC-related DTCs in the FLZCU (fault code: U1313-8, synchronization message received from the TBOX failed to be verified), the DTCs need to be cleared. Remote control function commands can be sent using a mobile app to check if the relevant functions are working properly.

[0138] For replacing only the TBOX, the procedure is the same as above for replacing both the TBOX and FLZCU. When replacing only the FLZCU, use a diagnostic tool to write the VIN into the FLZCU and send a restart command to the FLZCU. The FLZCU updates the SecOC key and clears the synchronization counter value. If there is a SecOC-related DTC in the FLZCU (fault code: U1313-8, synchronization message received from the TBOX failed to be verified), the DTC needs to be cleared. Use the mobile APP to send remote control function commands and check whether the relevant functions are normal.

[0139] As can be seen from the above-mentioned vehicle key processing and control method, this method can predict the current change path throughout the charging cycle, detect and classify dynamic changes in charging current in real time, and automatically compensate for thermal management time, thus realizing a high-precision calculation of the remaining charging time.

[0140] Corresponding to the above embodiments of the vehicle key processing and control method, this embodiment of the invention also provides a vehicle key processing and control system, such as... Figure 11 As shown, the system includes: Key initialization module 1110: used to generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU; Key generation module 1120: Used to control the communication encryption module corresponding to the vehicle ECU to obtain the original key corresponding to the vehicle identification code from the NVM memory, and use the vehicle identification code to generate the authentication key corresponding to the original key; Key update module 1130: used to update the original key in the NVM memory to the authentication key when the vehicle identification code is detected to be written to the vehicle ECU; Key processing module 1140: Used to control the vehicle ECU to perform key processing on the vehicle identification code and its corresponding authentication key.

[0141] As can be seen from the above-described vehicle-mounted key processing and control system, the system can perform randomness checks on the keys through the key initialization module to ensure that the keys have high entropy values, thereby solving the problem of insufficient key randomness. In addition, the system can determine the validity of the original keys through the key generation module, thereby solving the problem of poor reliability in the key storage and retrieval process. The system can clear the synchronization counter corresponding to the SecOC module through the key update module to avoid replay attacks, thereby improving the security of the key update and synchronization process. The system can standardize operations in the vehicle production and after-sales process through the key processing module, improving the compatibility of usage scenarios.

[0142] The vehicle key processing control system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned vehicle key processing control method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned vehicle key processing control method embodiment.

[0143] This embodiment also provides an electronic device, the structural schematic diagram of which is shown below. Figure 12 As shown, the device includes a processor 101 and a memory 102; wherein, the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the above-described vehicle key processing control method.

[0144] Figure 12 The electronic device shown also includes a bus 103 and a communication interface 104, with the processor 101, communication interface 104 and memory 102 connected via the bus 103.

[0145] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0146] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0147] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0148] This invention also provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of the vehicle key processing control method described in the foregoing embodiments.

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

[0150] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0151] In addition, the functional units in the various embodiments of the present invention 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.

[0152] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion 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, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0153] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A vehicle-mounted key processing control method, characterized in that, The method includes: Key initialization steps: Generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU; Key generation step: Control the communication encryption module corresponding to the vehicle ECU to obtain the original key corresponding to the vehicle identification code from the NVM memory, and use the vehicle identification code to generate the authentication key corresponding to the original key; Key update step: When the vehicle identification code is detected to be written to the vehicle ECU, the original key in the NVM memory is updated to the authentication key; Key processing steps: Control the vehicle ECU to perform key processing on the vehicle identification code and its corresponding authentication key.

2. The vehicle-mounted key processing control method according to claim 1, characterized in that, The key generation step includes: Obtain the vehicle type corresponding to the vehicle identification code, and use the vehicle type to determine the key length corresponding to the original key and its corresponding multiple unit bytes; Based on the key length, random numbers corresponding to each unit byte are generated sequentially, and the original key is generated based on the random numbers; Determine whether all the random numbers in the unit byte are the same; if so, regenerate the random numbers until all the random numbers are different; if not, write the original key to the NVM memory corresponding to the vehicle ECU.

3. The vehicle-mounted key processing control method according to claim 1, characterized in that, Writing and saving the original key to the NVM memory corresponding to the vehicle ECU includes: Obtain the NVM memory corresponding to the vehicle ECU, determine the preset storage address area in the NVM memory, and initialize the storage address area using preset initial values; The original key is controlled to be written to and saved to the storage address area; wherein the original key data in the storage address area is not erased when the NVM memory is updated.

4. The vehicle-mounted key processing control method according to claim 3, characterized in that, The key generation step includes: Initialize and acquire the board-side communication encryption module and key management module corresponding to the vehicle ECU; The key management module is controlled to retrieve the original key corresponding to the vehicle identification code from the NVM memory, and to determine whether the original key is the initial value; If the original key is not the initial value, then the authentication key is generated using the vehicle identification number and the original key; After the board-side communication encryption module sends a key reading command to the key management module, the response result of the key management module is monitored in real time. After encrypting and transmitting the response result based on the synchronization counter corresponding to the board-side communication encryption module, the authentication key is obtained based on the response result.

5. The vehicle-mounted key processing control method according to claim 4, characterized in that, The key update step includes: After initializing the vehicle ECU, determine whether the vehicle identification code has been written to the vehicle ECU; If so, obtain the key value corresponding to the authentication key and determine whether the key value has changed; If the key value has not changed, the synchronization counter is cleared, and the original key in the NVM memory is updated to the authentication key.

6. The vehicle-mounted key processing control method according to claim 5, characterized in that, The method further includes: If the key value changes, the HSM memory corresponding to the vehicle ECU is retrieved, and the authentication key is updated in the HSM memory.

7. The vehicle-mounted key processing control method according to claim 1, characterized in that, The key processing steps include: When a vehicle is in the production process, identify any abnormal data related to the vehicle's production process. The vehicle identification code and its corresponding abnormal data are used to generate a write instruction for the vehicle ECU, and the vehicle identification code is written to the vehicle ECU using the write instruction. After the vehicle ECU is restarted, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

8. The vehicle-mounted key processing control method according to claim 4, characterized in that, The key processing steps include: When a vehicle is in the after-sales stage, determine the maintenance data of the vehicle during the after-sales process; The vehicle identification code and its corresponding maintenance data are used to generate a write command for the vehicle ECU. After clearing the synchronization counter, the vehicle identification code is written to the vehicle ECU using the write command. After the vehicle ECU is restarted, the initialized communication encryption module is used to process the vehicle identification code and its corresponding authentication key.

9. A vehicle-mounted key processing and control system, characterized in that, The system includes: Key initialization module: used to generate an original key based on the vehicle identification code and save the original key to the NVM memory corresponding to the vehicle ECU; Key generation module: used to control the communication encryption module corresponding to the vehicle ECU to obtain the original key corresponding to the vehicle identification code from the NVM memory, and use the vehicle identification code to generate the authentication key corresponding to the original key; Key update module: used to update the original key in the NVM memory to the authentication key when the vehicle identification code is detected to be written to the vehicle ECU; Key processing module: used to control the vehicle ECU to perform key processing on the vehicle identification code and its corresponding authentication key.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the vehicle key processing control method according to any one of claims 1 to 8.

Images