Vehicle key configuration method, electronic equipment and vehicle

Abstract

The invention provides a vehicle key configuration method, electronic equipment and a vehicle, and the method is applied to a security service platform, and comprises the steps: responding to the received key configuration information sent by a key request end, and generating a first dynamic key based on the key configuration information; wherein the key configuration information comprises key request time and identification information of a to-be-configured vehicle; encrypting a to-be-configured key by using the first dynamic key to obtain a first ciphertext; and sending the first dynamic key and the first ciphertext to the key request end, so that the key request end performs key configuration on a to-be-configured vehicle based on the first dynamic key and the first ciphertext. According to the vehicle key configuration method, the electronic equipment and the vehicle provided by the invention, the security and reliability in the key configuration process can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of vehicle key configuration technology, and in particular to a vehicle key configuration method, electronic device and vehicle. Background Technology

[0002] After replacing the electronic controller on the production line or in the after-sales service of a vehicle, a 27-security key needs to be programmed into the vehicle's electronic controller to enable secure access verification based on the 27-security key, ensuring the safe operation of the electronic controller. However, the existing 27-security key programming process has problems such as low security and reliability. In particular, during the programming process on the production line, there is a risk of mass cracking, and programming errors are difficult to detect in a timely manner, affecting programming efficiency. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a vehicle key configuration method, electronic device and vehicle to solve the technical problem of low security and reliability of key filling in the prior art.

[0004] To achieve the above objectives, this application provides a vehicle key configuration method applied to a security service platform, the method comprising: In response to receiving key configuration information sent by the key requester, a first dynamic key is generated based on the key configuration information; wherein, the key configuration information includes the key request time and the identification information of the vehicle to be configured; The first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext. The first dynamic key and the first ciphertext are sent to the key request terminal so that the key request terminal can perform key configuration on the vehicle to be configured based on the first dynamic key and the first ciphertext.

[0005] Optionally, the identification information of the vehicle to be configured includes the vehicle body identification information and the electronic controller identification information; The generation of the first dynamic key based on the key configuration information includes: The first dynamic key is obtained by performing a hash operation based on the vehicle identification information, electronic controller identification information, and key request time of the vehicle to be configured.

[0006] Optionally, the step of encrypting the key to be configured using the first dynamic key to obtain the first ciphertext includes: The type of vehicle to be configured is determined based on the identification information of the vehicle to be configured; Based on the target encryption algorithm corresponding to the type of vehicle to be configured, the first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext.

[0007] Based on the same inventive concept, this disclosure also provides a second vehicle key configuration method, applied to the key request end, the method comprising: Receive the first dynamic key and the first ciphertext sent by the security service platform, and obtain the key request time used to generate the first dynamic key; The first dynamic key, the first ciphertext, and the key request time are encrypted based on the session key to obtain the first encrypted packet; The first encrypted packet is sent to the central controller on the vehicle to be configured, so that the central controller on the vehicle to be configured can perform key configuration based on the first encrypted packet.

[0008] Optionally, before receiving the first dynamic key and the first ciphertext, the method further includes: Obtain the identification information of the vehicle to be configured, and use the current time as the key request time; Generate key configuration information based on the identification information of the vehicle to be configured and the key request time; The key configuration information is sent to the security service platform so that the security service platform generates the first dynamic key.

[0009] Based on the same inventive concept, this disclosure also provides a third vehicle key configuration method, applied to a central controller in a vehicle, the method comprising: Receive the first encrypted packet sent by the key requester; Decrypt the first encrypted packet to obtain the first dynamic key, the first ciphertext, and the key request time; In response to the fact that the time difference between the key request time and the current time is less than a preset time difference threshold, a second dynamic key is calculated based on the current vehicle identification information and the key request time. In response to the fact that the second dynamic key is consistent with the first dynamic key, the first ciphertext is decrypted using the second dynamic key to obtain the key to be configured; The key to be configured is encrypted to obtain a second encrypted packet; The second encrypted packet is sent to the electronic controller on the current vehicle to configure the key for the current vehicle.

[0010] Optionally, the step of encrypting the key to be configured to obtain a second encrypted packet includes: Perform a hash calculation on the key to be configured to obtain a first hash value; Using a pre-stored preset key of the electronic controller, the first hash value and the key to be configured are encrypted to obtain the second encrypted packet.

[0011] Optionally, the current vehicle identification information includes the vehicle body identification information and the electronic controller identification information; The calculation of the second dynamic key based on the current vehicle's identification information and the key request time information includes: The second dynamic key is calculated based on the current vehicle body identification information, electronic controller identification information, and the key request time information.

[0012] Based on the same inventive concept, this disclosure also provides a vehicle key configuration device for use in a security service platform, the device comprising: The first key generation module is used to generate a first dynamic key based on the key configuration information received from the key request terminal; wherein the key configuration information includes the key request time and the identification information of the vehicle to be configured. The first encryption module is used to encrypt the key to be configured using the first dynamic key to obtain the first ciphertext; The first key distribution module is used to send the first dynamic key and the first ciphertext to the key request terminal, so that the key request terminal can perform key configuration on the vehicle to be configured based on the first dynamic key and the first ciphertext.

[0013] Based on the same inventive concept, this disclosure also provides another vehicle key configuration device, applied to a key request end, the device comprising: The first receiving module is used to receive the first dynamic key and the first ciphertext sent by the security service platform, and to obtain the key request time used to generate the first dynamic key; The second encryption module is used to encrypt the first dynamic key, the first ciphertext and the key request time based on the session key to obtain the first encrypted packet; The second key distribution module is used to send the first encrypted packet to the central controller on the vehicle to be configured, so that the central controller on the vehicle to be configured can perform key configuration based on the first encrypted packet.

[0014] Based on the same inventive concept, this disclosure also provides another vehicle key configuration device, applied to a central controller in a vehicle, the device comprising: The second receiving module is used to receive the first encrypted packet sent by the key requesting end; The first decryption module is used to decrypt the first encrypted packet to obtain the first dynamic key, the first ciphertext, and the key request time. The second key generation module is used to calculate a second dynamic key based on the current vehicle's identification information and the key request time in response to the time difference between the key request time and the current time being less than a preset time difference threshold. The second decryption module is used to decrypt the first ciphertext using the second dynamic key in response to the second dynamic key being consistent with the first dynamic key, so as to obtain the key to be configured. The third encryption module is used to encrypt the key to be configured to obtain a second encrypted packet; The third key distribution module is used to send the second encryption packet to the electronic controller on the current vehicle in order to configure the key for the current vehicle.

[0015] Based on the same inventive concept, this disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement a vehicle key configuration method as described above.

[0016] Based on the same inventive concept, this disclosure also provides a non-transitory computer-readable storage medium that stores computer instructions for causing a computer to execute a vehicle key configuration method as described above.

[0017] Based on the same inventive concept, this disclosure also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to execute a vehicle key configuration method as described above.

[0018] Based on the same inventive concept, this disclosure also provides a vehicle that includes the electronic equipment described above.

[0019] As can be seen from the above, the vehicle key configuration method, electronic device, and vehicle provided in this application enable the security service platform to generate a first dynamic key based on the key configuration information containing the key request time and the identification information of the vehicle to be configured when it receives the key configuration information sent by the key requesting end. This ensures that the first dynamic key is not only real-time and unique but also forms a clear one-to-one correspondence with the specific vehicle to be configured. Only the vehicle to be configured can decrypt the first ciphertext to obtain the corresponding key to be configured. When the first ciphertext is sent to other vehicles whose identification information is inconsistent with that of the vehicle to be configured, the corresponding vehicle cannot generate a key that matches the first dynamic key, and therefore cannot correctly decrypt the first ciphertext. This avoids the situation where the key to be configured is configured by the wrong vehicle, effectively improving the security and efficiency of key loading. At the same time, the first dynamic key changes dynamically with the key request time. Even for the same vehicle to be configured, the first dynamic key corresponding to different key configuration requests is different, making the first dynamic key unusable and further improving the security of key loading. In this application, the first dynamic key is made unique based on the key request time and the identification information of the vehicle to be configured, which effectively improves the security of the key configuration process, effectively prevents batch problems caused by incorrect key issuance during key filling on the production line, and effectively improves the efficiency and reliability of key filling. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of a vehicle key configuration method according to an embodiment of this application; Figure 2 This is a schematic diagram of another vehicle key configuration method according to an embodiment of this application; Figure 3 This is a schematic diagram of another vehicle key configuration method according to an embodiment of this application; Figure 4 This is a schematic diagram of a vehicle key configuration device according to an embodiment of this application; Figure 5 This is a schematic diagram of another vehicle key configuration device according to an embodiment of this application; Figure 6 This is a schematic diagram of another vehicle key configuration device according to an embodiment of this application; Figure 7 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0023] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0024] In automotive intelligent systems, the Electronic Control Unit (ECU) typically has multiple operating modes, such as a default mode and an enhanced diagnostic mode. The default mode is the ECU's normal operating state during daily vehicle use. In this mode, the ECU executes predetermined vehicle control functions and only exposes limited standard diagnostic interfaces for basic status monitoring and fault information reading. These interfaces typically only support basic operations such as parameter querying and fault code scanning, strictly restricting access to the ECU's core software, key parameters, and safety configurations to ensure functional and cybersecurity during vehicle operation.

[0025] When the ECU in a vehicle is in default mode, access to the ECU is strictly limited, and operations related to the ECU's core software or critical configurations are prohibited. Therefore, when performing operations that substantially affect the ECU's operational status, such as software flashing, deep repairs, or replacement of critical components, it is necessary to switch the ECU to enhanced diagnostic mode to unlock necessary operational permissions. Enhanced diagnostic mode is a high-privilege operating state. In this mode, the ECU unlocks more protected diagnostic services and control interfaces, allowing highly sensitive operations such as program flashing, secure access, and parameter calibration, providing the necessary conditions for vehicle software maintenance and system adaptation.

[0026] Because enhanced diagnostic mode involves access to critical resources within the ECU, to prevent security risks from unauthorized devices or illegal operations, the ECU typically employs a pre-set secure access mechanism to strictly control this mode. The 27-Security Key is a core element of this mechanism, used to implement access control and authorization management for high-privilege operations. In enhanced diagnostic mode, when a flashing or other high-privilege command is detected, the ECU initiates a secure access verification based on the 27-Security Key. The diagnostic device can only obtain the corresponding operating permissions after generating a correct response. This mechanism ensures that only authorized and legitimate diagnostic devices can perform critical operations in enhanced diagnostic mode, effectively preventing unauthorized tampering and unauthorized access.

[0027] Therefore, before a vehicle leaves the factory or during the ECU initialization phase, the 27-security key needs to be installed in a secure and controllable production line environment. Only after the 27-security key is configured in the ECU can the ECU initiate secure access verification during subsequent use and support various high-privilege operations in enhanced diagnostic mode. In after-sales parts replacement scenarios, newly installed ECUs also need to be configured with the corresponding 27-security key through a secure installation process to ensure consistency with the target vehicle's security system, thereby guaranteeing that diagnostic and maintenance operations throughout the vehicle's entire lifecycle are under a controllable and traceable security management framework.

[0028] In scenarios such as vehicle production line processes before leaving the factory or after-sales ECU replacement, the filling of 27-security keys is usually carried out using a fixed key distribution method. Specifically, for a batch of 27-security keys to be configured, they are encrypted and encapsulated using the same fixed key, and the encrypted key data is distributed to the corresponding vehicle; the vehicle side uses the pre-stored corresponding fixed key to decrypt the distributed data, thereby obtaining and storing the corresponding 27-security key.

[0029] However, the aforementioned key-based filling method has significant shortcomings in terms of both security and reliability. On the one hand, since the key is reused across multiple vehicles or ECUs, if it is leaked or cracked on the production line, diagnostic tools, or terminal side, the related 27-security keys will face the risk of being exposed in batches. This will lead to the overall failure of the ECU's secure access mechanism, making high-privilege operations such as enhanced diagnostics and flashing control vulnerable to unauthorized unlocking, thus posing a serious threat to the ECU's software integrity and system security.

[0030] On the other hand, the fixed key distribution method lacks the ability to differentiate between vehicles or ECUs, making it difficult to effectively avoid potential risks caused by key configuration errors. For example, during production line or after-sales operations, if the 27-security key originally belonging to vehicle A is mistakenly distributed to vehicle B, since both use the same fixed decryption key, vehicle B can still successfully decrypt and configure vehicle A's 27-security key, resulting in a configuration error. Once this type of misconfiguration occurs, it will cause the ECU's security access control to mismatch with the actual vehicle identity, thereby affecting the correctness of subsequent diagnosis, maintenance, and security management. Especially in mass configuration scenarios on the production line, key filling is usually carried out continuously according to a fixed rhythm and sequence. When a key mismatch occurs in the configuration process of a certain vehicle, subsequent vehicles will still use the same filling process and fixed key, and the distribution error may be continuously amplified and propagated to multiple vehicles or ECUs, thus causing batch configuration deviations. The above-mentioned chain errors are often difficult to detect in the early stages and only become apparent in the later stages, such as vehicle delivery or after-sales diagnosis. This not only affects the key filling efficiency but also directly impacts the delivery schedule and operational safety of the entire batch of vehicles.

[0031] Meanwhile, regardless of whether it's a traditional gasoline-powered vehicle or a new energy vehicle, all ECUs rely on the 27-Security Key for secure access control in enhanced diagnostic mode. However, different vehicle platforms typically differ in ECU architecture, diagnostic strategies, and security policies. When the 27-Security Key is misconfigured—for example, if the 27-Security Key for a gasoline-powered vehicle is mistakenly configured for a new energy vehicle, or vice versa—even if the configuration process appears to be complete, the relevant ECU may still fail to respond correctly to the secure access process during subsequent operation, potentially leading to abnormal unlocking or incorrect authorization of high-privilege operations. These cross-vehicle or cross-platform key mismatch issues directly undermine the trust relationship between the ECU and the overall vehicle security system, potentially causing uncontrolled diagnostic access, abnormal maintenance operations, and ultimately affecting the normal operation of the ECU and even the functional and operational safety of the entire vehicle.

[0032] Therefore, given the current context of large-scale vehicle production and highly diversified vehicle platforms, the existing 27-security key filling method suffers from poor security and reliability. It should be noted that the key filling discussed below includes both pre-shipment key filling and filling after ECU replacement.

[0033] In view of this, this application provides a vehicle key configuration method that can effectively improve the security and reliability of key configuration.

[0034] As attached Figure 1 As shown, the method is applied to a security service platform and specifically includes: S101. In response to receiving key configuration information sent by the key request terminal, generate a first dynamic key based on the key configuration information; wherein, the key configuration information includes the key request time and the identification information of the vehicle to be configured; Specifically, the Secure Service Platform (SSP) can have a key pool storing multiple keys to be configured. These keys can be distributed according to a preset fixed rhythm or sequence. For example, when the SSP receives a key configuration message, it allocates a usable key from the key pool in a predetermined order. The key requester can be a detection device. Before performing the key configuration operation, the detection device first establishes a communication connection with the vehicle to be configured to obtain its identification information, uses the current time as the key request time, generates key configuration information based on the vehicle's identification information and the key request time, and then sends the key configuration information to the SSP to initiate the key configuration process.

[0035] S102. Use the first dynamic key to encrypt the key to be configured to obtain the first ciphertext; Specifically, the key to be configured is a 27-security key. When the key configuration information sent by the key requester is received, the security service platform generates a first dynamic key based on the key configuration information, allocates an available key to be configured from the key pool for the key configuration information or the first dynamic key, and then uses the first dynamic key to encrypt the corresponding key to be configured, thereby obtaining the first ciphertext.

[0036] In this step, the first dynamic key is not a fixed, universal key, but rather dynamically generated based on the key request time and the identification information of the vehicle to be configured. It is not only unique but also forms a one-to-one correspondence with the specific vehicle to be configured, ensuring that the first ciphertext is only valid for that vehicle. When the first ciphertext is sent to another vehicle whose identification is inconsistent with the one used for its generation, that vehicle cannot generate a key matching the first dynamic key, and therefore cannot correctly decrypt the first ciphertext, and the configured key cannot be configured successfully. This effectively avoids the risk of the configured key being configured by the wrong vehicle due to incorrect key distribution, enhancing the security and reliability of the key configuration process. Furthermore, by introducing the key request time as a dynamic factor in the generation of the first dynamic key, key configuration requests initiated at different times will generate different first dynamic keys. Even for the same vehicle, the first dynamic keys generated at different times will be different, thus giving the encryption process a clear time-sensitive characteristic. With this dynamically changing key generation mechanism, even if a dynamic key or its corresponding first ciphertext is leaked, the impact is limited to the corresponding vehicle and the current request scenario. It is difficult to reuse or extend to other vehicles or subsequent requests, thus avoiding the risk of batch leakage of the key to be configured due to the reuse of fixed keys, and further increasing the security and reliability of the key configuration process.

[0037] S103. Send the first dynamic key and the first ciphertext to the key request terminal so that the key request terminal can perform key configuration on the vehicle to be configured based on the first dynamic key and the first ciphertext.

[0038] Specifically, the security service platform sends the generated first dynamic key and the first ciphertext encrypted using the first dynamic key to the key request terminal that initiated the key request (i.e., the key request terminal that sends the key configuration information). After receiving the first dynamic key and the first ciphertext, the key request terminal then encrypts and transmits the first dynamic key, the first ciphertext, and the key request time used to generate the first dynamic key to the central controller (CEM, Central Electronic Module, or also known as the central electronic control module, body electronic controller, body controller, etc.) of the vehicle to be configured. The CEM of the vehicle to be configured verifies the first dynamic key and decrypts the first ciphertext, and finally configures the key to be configured into the ECU of the vehicle to be configured.

[0039] In this application, based on steps S101 to S103, when the security service platform receives the key configuration information sent by the key requester, it generates a first dynamic key based on the key configuration information containing the key request time and the identification information of the vehicle to be configured. This ensures that the first dynamic key is not only real-time and unique, but also forms a clear one-to-one correspondence with the specific vehicle to be configured. Only the vehicle to be configured can decrypt the first ciphertext to obtain the corresponding key to be configured. When the first ciphertext is sent to other vehicles whose identification information is inconsistent with that of the vehicle to be configured, the corresponding vehicle cannot generate a key that matches the first dynamic key, and therefore cannot correctly decrypt the first ciphertext. This avoids the situation where the key to be configured is configured by the wrong vehicle, effectively improving the security and efficiency of key loading. At the same time, the first dynamic key changes dynamically with the key request time. Even for the same vehicle to be configured, the first dynamic key corresponding to different key configuration requests is different, making the first dynamic key unusable and further improving the security of key loading. In this application, the first dynamic key is made unique based on the key request time and the identification information of the vehicle to be configured, which effectively improves the security of the key configuration process, effectively prevents batch problems caused by incorrect key issuance during key filling on the production line, and effectively improves the efficiency and reliability of key filling.

[0040] To further enhance the security of the first dynamic key, the vehicle identification information and electronic controller identification information of the vehicle to be configured can be used together to determine the first dynamic key. In some embodiments, the identification information of the vehicle to be configured includes the vehicle identification information and electronic controller identification information. The generation of the first dynamic key based on the key configuration information includes: The first dynamic key is obtained by performing a hash operation based on the vehicle identification information, electronic controller identification information, and key request time of the vehicle to be configured.

[0041] Specifically, the Vehicle Identification Number (VIN) is a unique identifier for each vehicle, used to distinguish different vehicles and achieve vehicle-level identity management. The Unit Identification Number (UIN) is a unique identifier for the ECU. The first dynamic key can be calculated using the SHA-256 hash algorithm based on the VIN, UIN, and key request time of the vehicle to be configured. Alternatively, other hash algorithms can be used to calculate the first dynamic key, depending on the specific circumstances; there are no restrictions.

[0042] In this embodiment, a first dynamic key is calculated based on the vehicle identification number (VIN), electronic controller identification number (UIN), and key request time of the vehicle to be configured. This enables the first dynamic key to be bound to the vehicle identification number and electronic controller identification number of the vehicle to be configured, forming a one-to-one correspondence between the vehicle, the ECU, and the key to be configured. This further improves the security of the first dynamic key, thereby further improving the security and reliability of key filling.

[0043] Different vehicle models' ECUs may employ different encryption algorithms. For example, the encryption algorithms used in gasoline vehicles and new energy vehicles differ to some extent. Therefore, the appropriate encryption algorithm can be automatically selected based on the vehicle type to encrypt the configuration key. In some embodiments, encrypting the configuration key using the first dynamic key to obtain the first ciphertext includes: The type of vehicle to be configured is determined based on the identification information of the vehicle to be configured; Based on the target encryption algorithm corresponding to the type of vehicle to be configured, the first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext.

[0044] Specifically, existing gasoline-powered vehicles and new energy vehicles differ in their electronic and electrical architecture, safety design requirements, and cryptographic systems. The ECUs in different vehicle types typically employ different encryption algorithms during the design phase. Generally, gasoline-powered vehicle ECUs are built upon mature, internationally recognized cryptographic algorithms, such as AES-256 symmetric encryption algorithms; while new energy vehicles, in their safety system design, usually incorporate domestic cryptographic compliance requirements and employ national cryptographic symmetric encryption algorithms such as SM4. Based on these differences, during the encryption process of the key to be configured, the first dynamic key determines the type of vehicle to be configured based on the vehicle's identification information. When it is a gasoline-powered vehicle, the target encryption algorithm is the key system used by the gasoline-powered vehicle ECU, i.e., the AES-256 encryption algorithm; when it is a new energy vehicle, the target encryption algorithm is the key system used by the new energy vehicle ECU, i.e., the SM4 encryption algorithm. This allows the system to automatically select the corresponding encryption algorithm based on the type of vehicle to be configured, ensuring that the vehicle can decrypt the first ciphertext using its configured encryption algorithm.

[0045] In this step, the vehicle type can be determined based on the Vehicle Identification Number (VIN) or Electronic Controller Identification Number (UIN) of the vehicle to be configured. The safety service platform can parse specific segments in the VIN of the vehicle to be configured based on pre-configured VIN parsing rules and combine this with a vehicle configuration database to determine the vehicle type corresponding to the VIN. For example, different vehicle platforms and powertrains usually have distinguishing identifiers in the VIN encoding rules; the vehicle type can be identified by looking up a table or matching rules. Different vehicle types correspond to ECUs with significant differences in hardware architecture and application scenarios. ECUs for gasoline vehicles and new energy vehicles often use different model series or controller platforms. The safety service platform can parse the UIN of the vehicle to be configured based on pre-configured UIN parsing rules and compare it with an ECU model mapping table to determine the vehicle type of the target ECU, thereby indirectly identifying whether the vehicle is a gasoline vehicle or a new energy vehicle.

[0046] In this embodiment, the type of the vehicle to be configured is determined based on its identification information, and then the target encryption algorithm matching its type is used to encrypt the key to be configured. When it is necessary to configure keys for different types of vehicles, it is not necessary to frequently switch the encryption algorithm of the first ciphertext, thereby improving the security and adaptability of the key filling process under different vehicle models and effectively improving the key filling efficiency.

[0047] In some embodiments, it also includes: Generate a key configuration traceability code and create a traceability record associated with the key configuration traceability code; The key configuration traceability code, along with the first dynamic key and the first ciphertext, is sent to the key request terminal.

[0048] Specifically, while generating the first dynamic key, the security service platform can also generate a key configuration traceability code to identify this key configuration process. The key configuration traceability code can be a fixed-format identifier of 32 bits, generated, for example, by hashing or encoding fields such as the key request time and security service platform identification information, and is used to identify a key configuration task in the backend system. Simultaneously, while generating the key configuration traceability code, the security service platform creates a traceability record in the backend that corresponds one-to-one with the traceability code, recording key information about this key configuration.

[0049] The traceability record may include at least: key configuration traceability code, key requester identifier, key request time, VIN and UIN of the vehicle to be configured, target encryption algorithm (such as AES-256 or SM4), index information of the corresponding key to be configured in the key pool, current key configuration status (e.g., pending distribution, distributed, configuration successful, configuration failed, etc.), one or more transmission nodes, storage nodes, etc. In the subsequent configuration process, the key configuration traceability code is transmitted along with the key to be configured to the final storage node, i.e., the ECU of the vehicle to be configured. Each intermediate transmission node (such as the key requester and the CEM of the vehicle to be configured) and the final storage node (the ECU of the vehicle to be configured), upon receiving the corresponding data packet, feeds back the key configuration traceability code and the corresponding node information to the security service platform. For example, after receiving the first dynamic key, the first ciphertext, and the key configuration traceability code, the key requester sends the key configuration traceability code and a message indicating that the data has been successfully received to the security service platform. Upon receiving the key configuration traceability code and the message indicating that the data has been successfully received, the security service platform records the information in the corresponding traceability record based on the key configuration traceability code. For example, it records the identification information of the key requester on the transmission node, indicating that the corresponding key to be configured has been transmitted to the key requester. After the CEM of the vehicle to be configured decrypts and obtains the key to be configured, it configures the key. The information indicating that the traceability code and data have been successfully received is fed back to the security service platform. Upon receiving this information, the security service platform records the information in the corresponding traceability record based on the key configuration traceability code. For example, it records the CEM identification information of the vehicle to be configured at the transmission node, indicating that the key to be configured has been transmitted to the CEM of the vehicle to be configured. Once the ECU decrypts the key to be configured and completes its storage, it returns the information indicating that the key configuration traceability code and data have been successfully stored to the CEM of the vehicle to be configured. The CEM of the vehicle to be configured then returns this information to the security service platform. Upon receiving this information, the security service platform records the information in the traceability record corresponding to the key configuration traceability code. For example, it records the ECU identification information of the vehicle to be configured at the storage node, indicating that the corresponding key to be configured has been successfully configured. Simultaneously, it can modify the current key configuration status to "configuration successful," etc.

[0050] In this embodiment, after receiving the key configuration information, not only is a first dynamic key generated, but also a key configuration traceability code is generated to identify the current key configuration process. A corresponding traceability record is created based on the key configuration traceability code to record the entire configuration information of the current key configuration process. The key configuration traceability code is transmitted to each node along with the key to be configured, and finally reaches the storage node of the key to be configured (i.e., the ECU of the vehicle to be configured). Each intermediate transmission node (key request end, CEM of the vehicle to be configured) and the final storage node (ECU of the vehicle to be configured) report the corresponding information to the security service platform according to their own operation, and return the key configuration traceability code as is. The key configuration traceability code acts as an index tag throughout the entire configuration chain. The security service platform can quickly locate the corresponding traceability record based on this traceability code and query all information related to the key configuration, such as the vehicle, ECU, and current configuration status. When subsequent key configuration anomalies or security incident investigations occur, only the corresponding key configuration traceability code needs to be provided to fully track and assign responsibility for the 27-security key filling process, quickly locate key configuration leakage or abnormal nodes, and thus significantly improve the traceability of the key configuration process.

[0051] Based on the same inventive concept, this application also provides a vehicle key configuration method, applied to the key request end.

[0052] As attached Figure 2 As shown, the method includes: S201. Receive the first dynamic key and the first ciphertext sent by the security service platform, and obtain the key request time used to generate the first dynamic key; Specifically, the first dynamic key and first ciphertext received by the key requesting end are generated and sent using a vehicle key configuration method applied to the security service platform. The specific generation process of the first dynamic key and first ciphertext includes: generating a first dynamic key based on the key configuration information sent by the key requesting end, and then using the first dynamic key to encrypt the key to be configured to obtain the first ciphertext. After receiving the first dynamic key and first ciphertext from the security service platform, the key requesting end obtains the key request time stored when it initiated the key request. This key request time is the same as the key request time in the key configuration information sent to the security service platform. In addition, the security service platform can also send the key request time received, used to generate the first dynamic key, along with the first dynamic key and first ciphertext. The key requesting end receives the key request time at the same time as receiving the first dynamic key and first ciphertext.

[0053] In this step, when the security service platform generates and issues the key configuration traceability code, the key requesting end receives the key configuration traceability code at the same time as receiving the first dynamic key and the first ciphertext. After receiving the code, the key requesting end returns the successful reception information and the key configuration traceability code to the security service platform so that the security service platform can update the corresponding traceability record.

[0054] S202. Encrypt the first dynamic key, the first ciphertext, and the key request time based on the session key to obtain a first encrypted packet; Specifically, prior to this step, the key requester establishes encrypted communication with the CEM on the vehicle to be configured. The key requester generates a session key, encrypts it using the preset public key of the CEM on the vehicle to be configured, and obtains a second ciphertext. This second ciphertext is then sent to the CEM on the vehicle to be configured. Upon receiving the second ciphertext, the CEM on the vehicle to be configured decrypts it using its own stored preset private key paired with the preset public key, thus obtaining the session key. This allows the key requester and the CEM on the vehicle to be configured to transmit data encryptedly using the session key.

[0055] In this step, the key requester can also encrypt the first dynamic key, the first ciphertext, the key request time, and the key configuration traceability code together based on the session key to obtain the first encrypted packet. This allows the key configuration traceability code to be transmitted to the next node (i.e., the CEM of the vehicle to be configured) along with the key to be configured (i.e., the first ciphertext).

[0056] S203. The first encryption packet is sent to the central controller on the vehicle to be configured, so that the central controller on the vehicle to be configured can perform key configuration based on the first encryption packet.

[0057] Specifically, the key requester pre-establishes an encrypted communication channel based on a session key with the CEM (Content Management Electronics) on the vehicle to be configured. When the CEM receives the first encrypted packet, it decrypts it using the pre-stored session key to obtain the corresponding configuration key. This configuration key is then sent to the ECU (Electronic Control Unit) on the vehicle, allowing it to be successfully written into the ECU. In this step, after sending the first encrypted packet, the key requester returns the key transmission information along with the key configuration traceability code to the security service platform, enabling the platform to update the corresponding traceability record.

[0058] In this application, based on steps S201-S203, the key requesting end receives the first dynamic key and the first ciphertext issued by the security service platform, and obtains the key request time used to generate the first dynamic key. The first dynamic key is generated based on the identification information of the vehicle to be configured and the key request time, and has uniqueness for a specific vehicle and a specific request time. On this basis, the key requesting end re-encrypts and encapsulates the first dynamic key, the first ciphertext, and the key request time based on the session key to form a first encrypted packet, and sends the first encrypted packet to the central controller on the vehicle to be configured. Through session-level encryption and encapsulation, the first dynamic key and the first ciphertext are bound to the current communication session, effectively preventing encrypted data from being replayed or misused between different sessions or different vehicles. At the same time, the key requesting end is only responsible for key request, encryption and encapsulation, and secure forwarding in the entire key configuration process, and does not directly access the plaintext of the key to be configured, reducing the risk of the key being exposed on the key requesting end side. Meanwhile, the vehicle-specificity and timeliness of the first dynamic key ensure that even if abnormal acquisition occurs during transmission, its impact is limited to a single vehicle and a single request scenario, preventing cascading effects on other vehicles or subsequent key configurations. This is particularly effective in the production line filling process of the 27-security key, enabling effective isolation and risk mitigation of the 27-security key configuration process at the key request end. The vehicle key configuration method of this application effectively improves the security and reliability of the key to be configured during transmission at the key request end, thereby enhancing the security and reliability of the entire key filling process.

[0059] Key configuration information is obtained from the vehicle to be configured via a key request terminal. In some embodiments, before receiving the first dynamic key and the first ciphertext, the process further includes: Obtain the identification information of the vehicle to be configured, and use the current time as the key request time; Generate key configuration information based on the identification information of the vehicle to be configured and the key request time; The key configuration information is sent to the security service platform so that the security service platform generates the first dynamic key.

[0060] Specifically, when configuring a vehicle with a 27-security key, the detection device first connects to the vehicle to be configured and obtains the vehicle identification information of the vehicle. At this time, the detection device acts as the key requesting end. The identification information of the vehicle to be configured includes the vehicle identification number (VIN) and the electronic controller identification number (UIN).

[0061] In this embodiment, key configuration information is obtained through the key request end and sent to the security service platform to start the key configuration process for the vehicle to be configured. This ensures that the subsequent key configuration process is only valid for the vehicle to be configured, effectively preventing the key to be configured from being misconfigured in cross-vehicle scenarios. Furthermore, dynamic changes are introduced by utilizing request time to avoid the key being reused between different requests, thereby improving the accuracy and security of the entire key configuration process.

[0062] Based on the same inventive concept, this application also provides a vehicle key configuration method, applied to the central controller of a vehicle.

[0063] As attached Figure 3 As shown, the method includes: S301, Receive the first encrypted packet sent by the key requesting end; Specifically, the first encrypted packet received in this step is generated and sent by the vehicle key configuration method applied to the key requesting end. The method for generating the first encrypted packet includes: the key requesting end encrypts the first dynamic key, the first ciphertext and the key request time based on the session key to obtain the first encrypted packet.

[0064] S302. Decrypt the first encrypted packet to obtain the first dynamic key, the first ciphertext, and the key request time; Specifically, prior to this step, the CEM on the vehicle has pre-established an encrypted communication channel with the key requester. After receiving the second ciphertext sent by the key requester, the CEM on the vehicle decrypts the second ciphertext using its own stored preset private key to obtain the session key. After obtaining the first encrypted packet, the first encrypted packet can be decrypted using the session key obtained from the key requester, thereby successfully extracting the first dynamic key, the first ciphertext, and the key request time.

[0065] In this step, if the first encrypted packet contains a key configuration traceability code, the CEM on the vehicle can extract the key configuration traceability code after decrypting the first encrypted packet. After extracting the key configuration traceability code, the CEM returns the data reception success message along with the key configuration traceability code to the security service platform, so that the security service platform can update the corresponding traceability record. Specifically, the CEM on the vehicle can first return the data reception success message and the key configuration traceability code to the key requester, and then the key requester returns it to the security service platform, or the CEM can directly return it to the security service platform; there are no specific restrictions.

[0066] S303. In response to the fact that the time difference between the key request time and the current time is less than a preset time difference threshold, a second dynamic key is calculated based on the current vehicle identification information and the key request time. Specifically, the preset time difference threshold can be set to 5 minutes, 10 minutes, or, depending on the actual situation, 3, 4, 6, 7, 8 minutes, etc., with no specific restrictions. Before calculating the second dynamic key, the time difference between the key request time and the current time is verified. Only when the time difference is less than the preset time difference threshold will the calculation of the second dynamic key continue based on the current vehicle identification information and the key request time. When the time difference between the key request time and the current time is greater than or equal to the preset time difference threshold, it indicates that the key request has exceeded the allowed time window. At this time, CEM will no longer calculate the second dynamic key or decrypt the first ciphertext, and will directly terminate the current key configuration process. The corresponding abnormal status or error information can be recorded and fed back to the security service platform along with the key configuration traceability code for subsequent investigation and tracing. When the time difference between the key request time and the current time is too long, it usually means that there is an anomaly in the transmission or processing of the key configuration information, the first dynamic key, or the first ciphertext, or there may even be a possibility that it has been abnormally obtained and re-initiated. Therefore, the first ciphertext is no longer trusted data at this point. In order to ensure the safe operation of the vehicle's CEM and ECU, the key configuration process is directly interrupted at this time.

[0067] S304. In response to the fact that the second dynamic key is consistent with the first dynamic key, the first ciphertext is decrypted using the second dynamic key to obtain the key to be configured. Specifically, since the first dynamic key is calculated based on the identification information of the vehicle to be configured, and the second dynamic key is calculated based on the identification information of the current vehicle, if the calculated first dynamic key and the second dynamic key are consistent, it means that the current vehicle is the vehicle to be configured in this key configuration process. At this time, the second dynamic key can be used to decrypt the first ciphertext to obtain the key to be configured. Conversely, when the calculated first dynamic key and the second dynamic key are inconsistent, it means that the identification information of the current vehicle is inconsistent with the identification information of the vehicle to be configured on which the first dynamic key was generated. That is, the vehicle currently participating in the configuration is not the vehicle to be configured corresponding to this key configuration process. At this time, the first ciphertext is discarded directly, the key configuration process is terminated, and the corresponding information, along with the key configuration traceability code, is fed back to the security service platform for subsequent investigation and traceability. Thus, when problems such as incorrect issuance of the key to be configured occur, the above problems can be detected in a timely manner, preventing incorrect key to be configured from being written to the vehicle.

[0068] S305. Encrypt the key to be configured to obtain a second encrypted packet; Specifically, after the vehicle's CEM decrypts the first ciphertext to obtain the key to be configured, it can use the pre-stored ECU default key to encrypt the key, resulting in a second encrypted packet. This secondary encryption of the key ensures that it remains protected throughout the process of being sent from the CEM to the target ECU, preventing its transmission in plaintext within the vehicle's internal communication links and thus enhancing the security of the ECU key writing phase. The ECU default key is a basic security key already present in the ECU at the factory. When performing secondary encryption, the CEM directly utilizes the ECU default key without modifying the ECU's hardware structure or adding new security chips or dedicated encryption modules. Instead, it directly reuses the default encryption and decryption capabilities already present in the ECU at the factory, thus avoiding any impact on the existing ECU hardware and software architecture and reducing system modification and deployment costs.

[0069] S306. The second encrypted packet is sent to the electronic controller on the current vehicle to configure the key for the current vehicle.

[0070] Specifically, the current vehicle's CEM can send the second encrypted packet to the current vehicle's ECU via the vehicle communication bus (such as CAN or Ethernet). At this point, the current vehicle's ECU becomes the storage and writing node for the key to be configured. Upon receiving the second encrypted packet, the ECU decrypts it using its preset default key to recover the corresponding key to be configured and writes it to its secure storage area, completing the configuration of the key. In this step, after sending the second encrypted packet, the CEM returns the key transmission information along with the key configuration traceability code to the security service platform, allowing the security service platform to update the corresponding traceability record.

[0071] In this application, based on steps S301-S306, the central controller on the vehicle receives the first encrypted packet sent by the key requester and decrypts it locally to obtain the first dynamic key, the first ciphertext, and the key request time. This enables the central controller to independently verify and control the legality of the key configuration request. The central controller first performs a time difference check between the key request time and the current time. Only when the time difference is less than a preset time difference threshold will it continue to calculate the second dynamic key, effectively preventing expired or replay requests from triggering subsequent key configuration operations. Based on this, the central controller calculates the second dynamic key based on the current vehicle's identification information and the key request time, and compares it with the first dynamic key. Since the first dynamic key is generated on the security service platform side based on the identification information of the vehicle to be configured and the key request time, it is unique for a specific vehicle and a specific request time. When the second dynamic key matches the first dynamic key, it can be confirmed that the current vehicle is the vehicle to be configured for this key configuration process, thus preventing the key from being decrypted and configured in a cross-vehicle or incorrect vehicle environment. After the dynamic key consistency verification passes, the central controller uses the second dynamic key to decrypt the first ciphertext to obtain the key to be configured. It then further encrypts the key to be configured to generate a second encrypted packet, which is sent to the ECU to complete the key writing. By centrally performing time verification, vehicle identity verification, and secondary encryption control, the key to be configured is subject to multiple constraints and protections before entering the ECU. This significantly improves the security, accuracy, and reliability of the key configuration process without increasing the complexity on the ECU side.

[0072] Before encrypting the key to be configured, its hash value is calculated to further verify the security of the key at the ECU. In some embodiments, encrypting the key to be configured to obtain a second encrypted packet includes: Perform a hash calculation on the key to be configured to obtain a first hash value; Using a pre-stored preset key of the electronic controller, the first hash value and the key to be configured are encrypted to obtain the second encrypted packet.

[0073] Specifically, the CEM on the current vehicle first performs a hash calculation on the key to be configured to generate a corresponding first hash value. The first hash value is used to characterize the content features of the key to be configured and forms a one-to-one correspondence with the key to be configured. For example, one-way hash algorithms such as SHA-256, SHA-3 or SM3 can be used to generate the corresponding first hash value, and there is no specific restriction. Then, the CEM calls the preset key of the electronic controller (i.e. the ECU default key) stored in advance to encrypt the first hash value and the key to be configured, and generates a second encrypted packet.

[0074] In this step, the key configuration traceability code, the first hash value, and the key to be configured can be encrypted together to obtain a second encrypted package. Thus, after decrypting the second encrypted package, the vehicle ECU can simultaneously obtain the first hash value, the key configuration traceability code, and the key to be configured. Once the key to be configured is successfully stored, the successful storage information and the key configuration traceability code are returned to the CEM. The CEM then feeds back the successful storage information and the key configuration traceability code to the security service platform, which updates the corresponding traceability record, completing the entire process of information recording and traceability for the key to be configured.

[0075] In this embodiment, a hash calculation is performed on the key to be configured before generating the second encrypted packet. Utilizing the one-way and irreversible nature of hash operations, data features for verification are generated without exposing the plaintext of the key to be configured. After the ECU receives and decrypts the second encrypted packet, the ECU can perform the hash calculation again based on the decrypted key to be configured and compare the calculation result with the first hash value to determine whether the key to be configured has been tampered with or is abnormal during transmission and writing. This allows for verification of the correctness and integrity of the key to be configured on the ECU side, thereby further improving the reliability and security of the key configuration process.

[0076] The second dynamic key is calculated using the current vehicle's VIN and UIN. In some embodiments, the current vehicle's identification information includes the vehicle's body identification information and electronic controller identification information; The calculation of the second dynamic key based on the current vehicle's identification information and the key request time information includes: The second dynamic key is calculated based on the current vehicle body identification information, electronic controller identification information, and the key request time information.

[0077] Specifically, the second dynamic key is calculated using the same calculation method as the first dynamic key, such as the SHA-256 hash algorithm, to ensure that the same dynamic key can be calculated.

[0078] In this embodiment, a second dynamic key is calculated based on the current vehicle identification number (VIN), electronic controller identification number (UIN), and key request time. This second dynamic key can be bound to the current vehicle identification number and electronic controller identification number, forming a one-to-one correspondence between the vehicle, the ECU, and the key to be configured. Thus, the second dynamic key carrying the current vehicle's identity information can be compared with the first dynamic key carrying the vehicle to be configured, enabling verification and checking of the key distribution process. When a key distribution error occurs, it can be detected in a timely manner, further improving the reliability and security of the key configuration process.

[0079] After receiving the second encrypted packet, the ECU on the vehicle can decrypt it using the preset default key to extract the first hash value and the key to be configured. Based on the key to be configured, a hash calculation is performed to obtain the second hash value. When the first hash value and the second hash value are consistent, it indicates that the key to be configured has not been tampered with and is a secure and legitimate key. At this time, the key to be configured is stored, and the key configuration is completed. After the key configuration is completed, a storage success message and a key configuration traceability code are returned to the CEM.

[0080] Once the vehicle's ECU completes the storage of the key to be configured, the key configuration process is complete. Taking the 27-security key as an example, after the ECU completes the storage of the 27-security key, the ECU has the corresponding secure access mechanism and can verify secure access requests initiated by the diagnostic device. When high-privilege operations such as flashing are required on the ECU, the diagnostic device first establishes a connection with the CEM on the vehicle and initiates a mode switch request containing device identification information to the CEM. After receiving the mode switch request, the vehicle's CEM initiates a dynamic verification request to the security service platform, so that the security service platform sends a dynamic verification code to the diagnostic device or the client bound to the diagnostic device. Subsequently, the operator inputs the dynamic verification code into the diagnostic device. The vehicle's CEM compares the dynamic verification code input by the diagnostic device with the dynamic verification code issued by the security service platform, and simultaneously determines whether the diagnostic device is an authorized device based on the device identification information. When the dynamic verification code comparison results match, and the diagnostic device is confirmed to be an authorized device, it indicates that the current diagnostic device is a legitimate device. At this time, the vehicle's CEM sends a mode switch command to the ECU, causing the ECU to switch to enhanced diagnostic mode. In enhanced diagnostic mode, the ECU on the vehicle enables high-privilege operation authorization for the testing device based on the 27-security key configured according to any of the foregoing embodiments (i.e., the key to be configured as described in any of the foregoing embodiments), thereby allowing the testing device to perform high-privilege operations such as flashing.

[0081] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0082] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0083] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a vehicle key configuration device.

[0084] refer to Figure 4 The device is applied to a security service platform and includes: The first key generation module 401 is used to generate a first dynamic key based on the key configuration information received from the key request terminal in response to the key configuration information received; wherein, the key configuration information includes the key request time and the identification information of the vehicle to be configured; The first encryption module 402 is used to encrypt the key to be configured using the first dynamic key to obtain the first ciphertext; The first key distribution module 403 is used to send the first dynamic key and the first ciphertext to the key request terminal, so that the key request terminal can perform key configuration on the vehicle to be configured based on the first dynamic key and the first ciphertext.

[0085] In some embodiments, the identification information of the vehicle to be configured includes the vehicle body identification information and the electronic controller identification information of the vehicle to be configured; The first key generation module 401 is also used to: The first dynamic key is obtained by performing a hash operation based on the vehicle identification information, electronic controller identification information, and key request time of the vehicle to be configured.

[0086] In some embodiments, the first encryption module 402 is further configured to: The type of vehicle to be configured is determined based on the identification information of the vehicle to be configured; Based on the target encryption algorithm corresponding to the type of vehicle to be configured, the first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext.

[0087] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0088] The apparatus described above is used to implement a vehicle key configuration method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0089] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides another vehicle key configuration device.

[0090] refer to Figure 5 The device is used at the key request end and includes: The first receiving module 501 is used to receive the first dynamic key and the first ciphertext sent by the security service platform, and to obtain the key request time used to generate the first dynamic key. The second encryption module 502 is used to encrypt the first dynamic key, the first ciphertext and the key request time based on the session key to obtain the first encrypted packet; The second key distribution module 503 is used to send the first encryption packet to the central controller on the vehicle to be configured, so that the central controller on the vehicle to be configured can perform key configuration based on the first encryption packet.

[0091] In some embodiments, a key request module is also included; The key request module is used to perform the following before receiving the first dynamic key and the first ciphertext: Obtain the identification information of the vehicle to be configured, and use the current time as the key request time; Generate key configuration information based on the identification information of the vehicle to be configured and the key request time; The key configuration information is sent to the security service platform so that the security service platform generates the first dynamic key.

[0092] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0093] The apparatus described above is used to implement a vehicle key configuration method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0094] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides another vehicle key configuration device.

[0095] refer to Figure 6 The device is used in a central controller of a vehicle and includes: The second receiving module 601 is used to receive the first encrypted packet sent by the key requesting end; The first decryption module 602 is used to decrypt the first encrypted packet to obtain the first dynamic key, the first ciphertext and the key request time; The second key generation module 603 is used to calculate a second dynamic key based on the current vehicle's identification information and the key request time in response to the time difference between the key request time and the current time being less than a preset time difference threshold. The second decryption module 604 is used to decrypt the first ciphertext using the second dynamic key in response to the second dynamic key being consistent with the first dynamic key, so as to obtain the key to be configured. The third encryption module 605 is used to encrypt the key to be configured to obtain a second encryption packet; The third key distribution module 606 is used to send the second encrypted packet to the electronic controller on the current vehicle in order to configure the key for the current vehicle.

[0096] In some embodiments, the third encryption module 605 is further configured to: Perform a hash calculation on the key to be configured to obtain a first hash value; Using a pre-stored preset key of the electronic controller, the first hash value and the key to be configured are encrypted to obtain the second encrypted packet.

[0097] In some embodiments, the current vehicle identification information includes the vehicle body identification information and the electronic controller identification information; The second key generation module 603 is also used to: The second dynamic key is calculated based on the current vehicle body identification information, electronic controller identification information, and the key request time information.

[0098] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0099] The apparatus described above is used to implement a vehicle key configuration method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0100] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a vehicle key configuration method as described in any of the above embodiments.

[0101] Figure 7This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0102] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0103] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0104] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0105] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0106] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0107] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0108] The electronic devices described above are used to implement a corresponding vehicle key configuration method in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0109] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute a vehicle key configuration method as described in any of the above embodiments.

[0110] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0111] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute a vehicle key configuration method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0112] Based on the same concept, corresponding to any of the above embodiments, this application also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0113] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0114] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0115] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0116] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0117] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0118] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0119] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0120] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the claims of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A vehicle key configuration method, characterized in that, Applied to a security service platform, the method includes: In response to receiving key configuration information sent by the key requester, a first dynamic key is generated based on the key configuration information; wherein, the key configuration information includes the key request time and the identification information of the vehicle to be configured; The first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext. The first dynamic key and the first ciphertext are sent to the key request terminal so that the key request terminal can perform key configuration on the vehicle to be configured based on the first dynamic key and the first ciphertext.

2. The vehicle key configuration method according to claim 1, characterized in that, The identification information of the vehicle to be configured includes the vehicle body identification information and the electronic controller identification information; The generation of the first dynamic key based on the key configuration information includes: The first dynamic key is obtained by performing a hash operation based on the vehicle identification information, electronic controller identification information, and key request time of the vehicle to be configured.

3. The vehicle key configuration method according to claim 1, characterized in that, The first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext, which includes: The type of vehicle to be configured is determined based on the identification information of the vehicle to be configured; Based on the target encryption algorithm corresponding to the type of vehicle to be configured, the first dynamic key is used to encrypt the key to be configured to obtain the first ciphertext.

4. A vehicle key configuration method, characterized in that, Applied to the key request end, the method includes: Receive the first dynamic key and the first ciphertext sent by the security service platform, and obtain the key request time used to generate the first dynamic key; The first dynamic key, the first ciphertext, and the key request time are encrypted based on the session key to obtain the first encrypted packet; The first encrypted packet is sent to the central controller on the vehicle to be configured, so that the central controller on the vehicle to be configured can perform key configuration based on the first encrypted packet.

5. A vehicle key configuration method according to claim 4, characterized in that, Before receiving the first dynamic key and the first ciphertext, the process further includes: Obtain the identification information of the vehicle to be configured, and use the current time as the key request time; Generate key configuration information based on the identification information of the vehicle to be configured and the key request time; The key configuration information is sent to the security service platform so that the security service platform generates the first dynamic key.

6. A vehicle key configuration method, characterized in that, The method, applied to a central controller in a vehicle, includes: Receive the first encrypted packet sent by the key requester; Decrypt the first encrypted packet to obtain the first dynamic key, the first ciphertext, and the key request time; In response to the fact that the time difference between the key request time and the current time is less than a preset time difference threshold, a second dynamic key is calculated based on the current vehicle identification information and the key request time. In response to the fact that the second dynamic key is consistent with the first dynamic key, the first ciphertext is decrypted using the second dynamic key to obtain the key to be configured; The key to be configured is encrypted to obtain a second encrypted packet; The second encrypted packet is sent to the electronic controller on the current vehicle to configure the key for the current vehicle.

7. A vehicle key configuration method according to claim 6, characterized in that, The encryption process of the key to be configured to obtain a second encrypted packet includes: Perform a hash calculation on the key to be configured to obtain a first hash value; Using a pre-stored preset key of the electronic controller, the first hash value and the key to be configured are encrypted to obtain the second encrypted packet.

8. A key configuration method according to claim 6, characterized in that, The current vehicle identification information includes the vehicle body identification information and the electronic controller identification information; The calculation of the second dynamic key based on the current vehicle's identification information and the key request time information includes: The second dynamic key is calculated based on the current vehicle body identification information, electronic controller identification information, and the key request time information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 6 to 8.

10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 9.

Images