Data processing method and electronic device for vehicle

Abstract

Embodiments of the present application provide a data processing method of a vehicle and an electronic device, wherein the method comprises: obtaining identification information of the vehicle and life cycle information of the vehicle from Internet of Vehicles terminal data to be stored by the vehicle; extracting multi-dimensional feature information associated with the vehicle from the identification information and the life cycle information respectively, wherein the multi-dimensional feature information comprises at least one target dimensional feature information, and the target dimensional feature information of different vehicles is different; generating a key for the Internet of Vehicles terminal data by using the multi-dimensional feature information; encrypting the Internet of Vehicles terminal data according to the key, and storing the encrypted Internet of Vehicles terminal data. The present application solves the technical problem of poor data processing effect of the vehicle.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data processing method and electronic device for a vehicle. Background Technology

[0002] Currently, vehicle-to-everything (V2X) terminal data encryption primarily employs fixed-key symmetric encryption. However, this method mainly relies on a "one key for multiple vehicles" approach. If the fixed key is leaked, the V2X terminal data of a large number of vehicles can be exposed. Furthermore, while the Key Management Service (KMS) managing these fixed keys offers high security, it depends on expensive hardware or external services, resulting in high maintenance costs. It also suffers from single points of failure and performance bottlenecks due to network dependencies, making it difficult to meet the low latency and large-scale scalability requirements of V2X terminal data. Therefore, the technical problem of poor vehicle data processing performance remains.

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

[0004] This application provides a vehicle data processing method and electronic device to at least solve the technical problem of poor data processing performance in vehicles.

[0005] According to one aspect of the embodiments of this application, a vehicle data processing method is provided, wherein the method may include: obtaining vehicle identification information and vehicle lifecycle information from vehicle-to-everything (V2X) terminal data to be stored; extracting multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively, wherein the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles; generating a key for V2X terminal data using the multi-dimensional feature information; encrypting the V2X terminal data according to the key; and storing the encrypted V2X terminal data.

[0006] Optionally, a key for encrypting vehicle network terminal data is generated using multi-dimensional feature information, including: mixing multi-dimensional feature information to obtain mixed feature information; and generating a key using the mixed feature information.

[0007] Optionally, the multi-dimensional feature information includes vehicle identification features, vehicle type features, and temporal features. The vehicle identification feature represents the vehicle's identity, the vehicle type feature represents the vehicle's configuration attributes, and the temporal feature represents the vehicle's entry time. The multi-dimensional feature information is mixed to obtain mixed feature information, including: interleaving the temporal features into the vehicle identification features to obtain initial mixed feature information, wherein the initial mixed feature information is obtained by mixing the temporal features and the vehicle identification features; deforming the vehicle type features, and inserting the deformed vehicle type features into the initial mixed feature information to obtain mixed feature information.

[0008] Optionally, a key is generated using the hybrid feature information, including: adding the version prefix and version suffix of the key derivation model to the hybrid feature information to obtain the hybrid feature information after addition; generating a hash value based on the hybrid feature information after addition and the salt value using the key derivation model; and generating a key using the hash value.

[0009] Optionally, a hash value is generated using a key derivation model based on the added mixed feature information and the salt value, including: in response to the current iteration being the first iteration, using the key derivation model, in the first iteration, generating the hash value of the first iteration based on the added mixed feature information and the initial salt value; and a generation step, in response to the existence of a previous iteration and a next iteration in the current iteration, using the key derivation model, determining the hash value of the previous iteration as the salt value of the current iteration, and generating the hash value of the current iteration based on the added mixed feature information and the salt value of the current iteration, and incrementing the iteration number by one.

[0010] Optionally, a key is generated using a hash value, including: determining the hash value of the current iteration as the salt value for the next iteration, determining the next iteration as the current iteration, and repeating the generation steps until the number of iterations equals an iteration number threshold, and generating a key that meets a preset key length based on the hash value of the iteration number threshold.

[0011] Optionally, the vehicle identification information can be obtained from the vehicle-to-everything (V2X) terminal data to be stored, including: verifying the V2X terminal data to be stored and obtaining the verification result; and extracting the identification information from the V2X terminal data that the verification result indicates has authenticity and completeness.

[0012] Optionally, the vehicle-to-everything (V2X) terminal data to be stored is verified to obtain a verification result, including: verifying the V2X terminal data to be stored using the data signature of the V2X terminal data to obtain a first verification result, wherein the data signature is used to indicate the authenticity of the vehicle from which the V2X terminal data originates, and the first verification result is used to indicate whether the V2X terminal data to be stored is authentic; comparing the hash value contained in the V2X terminal data to be stored with the hash value calculated based on the V2X terminal data to obtain a comparison result; and verifying the V2X terminal data to be stored based on the comparison result to obtain a second verification result, wherein the second verification result is used to indicate whether the V2X terminal data to be stored is complete.

[0013] According to another aspect of the embodiments of this application, another vehicle data processing method is also provided, which is applied to a cloud server. The method further includes: in response to acquiring vehicle-to-everything (V2X) terminal data to be stored, acquiring vehicle identification information and vehicle lifecycle information from the V2X terminal data; extracting multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively, wherein the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles; generating a key for encrypting the V2X terminal data using the multi-dimensional feature information; encrypting the V2X terminal data according to the key; and storing the encrypted V2X terminal data in a database on the cloud server.

[0014] According to another aspect of the embodiments of this application, a vehicle data processing apparatus is also provided. The apparatus may include: a first acquisition module, configured to acquire vehicle identification information and vehicle lifecycle information from vehicle-to-everything (V2X) terminal data to be stored; a first extraction module, configured to extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively, wherein the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles; a first generation module, configured to generate a key for the V2X terminal data using the multi-dimensional feature information; and a first encryption module, configured to encrypt the V2X terminal data according to the key and store the encrypted V2X terminal data.

[0015] According to another aspect of the embodiments of this application, another vehicle data processing apparatus is also provided. The apparatus may include: a second acquisition module, configured to, in response to acquiring vehicle-to-everything (V2X) terminal data to be stored, acquire vehicle identification information and vehicle lifecycle information from the V2X terminal data; a second extraction module, configured to extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively, wherein the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles; a second generation module, configured to generate a key for encrypting the V2X terminal data using the multi-dimensional feature information; a second encryption module, configured to encrypt the V2X terminal data according to the key; and a storage module, configured to store the encrypted V2X terminal data in a database on a cloud server.

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

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

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

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

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

[0021] In this embodiment, if vehicle network terminal data that needs to be stored is detected, the vehicle's identification information and lifecycle information can be obtained from the vehicle network terminal data. Multi-dimensional feature information associated with the vehicle can be extracted from the identification information and lifecycle information. This multi-dimensional feature information can be used to generate a key for the vehicle network terminal data. The vehicle network terminal data can be encrypted using this key, and the encrypted data can be stored. In other words, in this embodiment, by extracting multi-dimensional features from the vehicle's identification information and lifecycle information and dynamically generating a key, a "one vehicle, one key" approach is achieved, avoiding the risk of exposing a large amount of vehicle network terminal data due to the leakage of fixed keys. This method does not rely on expensive hardware or external KMS services, eliminating network dependence, single points of failure, and high maintenance costs. It effectively avoids the shortcomings of related technologies in terms of security, scalability, and low latency, thereby improving the technical effect of vehicle data processing and solving the technical problem of poor vehicle data processing performance. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram illustrating an application scenario of vehicle data processing according to an embodiment of this application; Figure 2 This is a flowchart of a vehicle data processing method according to an embodiment of this application; Figure 3 This is a flowchart of another vehicle data processing method according to an embodiment of this application; Figure 4 This is a flowchart of a cloud-based vehicle data augmentation key derivation encryption method according to an embodiment of this application; Figure 5 This is a flowchart of a cloud-based vehicle data augmentation key derivation and decryption method according to an embodiment of this application; Figure 6 This is a schematic diagram of a vehicle data processing device according to an embodiment of this application; Figure 7 This is a schematic diagram of another vehicle data processing device according to an embodiment of this application; Figure 8 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

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

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

[0025] Figure 1 This is a schematic diagram illustrating an application scenario of vehicle data processing according to an embodiment of this application, such as... Figure 1 As shown, the above scenario may include terminal device 10, network 20, and cloud server 30. Terminal device 10 can be used to acquire vehicle-to-everything (V2X) terminal data uploaded by the vehicle. This terminal device can be an in-vehicle terminal device, such as the driver's mobile phone or computer, or a vehicle-mounted infotainment system. The V2X terminal data can be sent to cloud server 30 via network 20. At this point, cloud server 30 needs to be able to execute steps S102 to S108 to realize the vehicle data processing procedure.

[0026] The following steps can be executed via cloud server 30: Step S102, in response to the query information received by the question-and-answer interaction system in the vehicle, determine the driver or passenger from which the query information comes; Step S104, call the vehicle's memory model to detect the driver or passenger and obtain the detection result of the driver or passenger; Step S106, based on the detection result and the vehicle's operating status information associated with the driver or passenger, generate response information to answer the query information; Step S108, control the question-and-answer interaction system to output the response information.

[0027] In this embodiment, through steps S102 to S108, multi-dimensional features are extracted from the vehicle's identification information and lifecycle information to dynamically generate a key, achieving "one key per vehicle." This avoids the risk of exposing a large amount of vehicle network terminal data due to the leakage of fixed keys. The above method does not rely on expensive hardware or external KMS services, eliminating network dependence, single points of failure, and high maintenance costs. It effectively avoids the shortcomings of related technologies in terms of security, scalability, and low latency, thereby improving the technical effect of vehicle data processing and solving the technical problem of poor vehicle data processing performance.

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

[0029] This embodiment provides a vehicle data processing method. Figure 2 This is a flowchart of a vehicle data processing method according to an embodiment of this application, such as... Figure 2 As shown, the method may include the following steps.

[0030] Step S202: Obtain the vehicle's identification information and lifecycle information from the vehicle network terminal data to be stored.

[0031] In the technical solution provided by step S202 of this application embodiment, the vehicle-to-everything (V2X) terminal data can refer to the raw business data packets collected by the vehicle-mounted terminal equipment and reported to the cloud server. The aforementioned V2X terminal data may include vehicle operating status, location information, and sensor readings, etc. The aforementioned V2X terminal data can also be referred to as raw data packets.

[0032] Optionally, the aforementioned identification information may refer to static attribute data used to identify the vehicle's identity and specifications. This identification information may include a Vehicle Identification Number (VIN) and a model code. The VIN may be an internationally recognized unique vehicle identification code used to distinguish different vehicles. The model code may be a data code used to identify the vehicle's model, configuration, and production batch.

[0033] Optionally, the aforementioned lifecycle information can refer to time-dimensional data reflecting the stage a vehicle is in from its production line debut to its current state. For example, the aforementioned lifecycle information could refer to the vehicle's entry into the warehouse. This entry date can be used to record the initial time when the vehicle officially enters the sales or usage phase.

[0034] In this embodiment, if vehicle network terminal data that needs to be stored is detected, the vehicle's identification information and vehicle lifecycle information can be obtained from the aforementioned vehicle network terminal data.

[0035] Optionally, during the process of obtaining vehicle identification information, since the vehicle network terminal data contains vehicle identity attribute data, the vehicle identification code and model code can be extracted as vehicle identification information by parsing the vehicle network terminal data. During the process of obtaining lifecycle information, data reflecting the vehicle's time attributes can be further extracted from the vehicle network terminal data. This data can then be used as the vehicle's lifecycle information.

[0036] In this embodiment of the application, the above method obtains the vehicle identification information and the vehicle lifecycle information from the vehicle network terminal data respectively, and combines the identification information and the lifecycle information. This not only ensures that each vehicle has unique identification information to distinguish its identity, but also increases the diversity of information required for key derivation by introducing lifecycle information.

[0037] Step S204: Extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively.

[0038] In the technical solution provided by step S204 of the embodiments of this application, the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles.

[0039] The aforementioned multi-dimensional feature information refers to a structured data set extracted from vehicle identification information and vehicle lifecycle information, used to characterize the vehicle's identity and time attributes. This multi-dimensional feature information can be constructed by combining specific fields from the vehicle identification code, the vehicle model code, and parsed data from the vehicle's entry date.

[0040] The aforementioned target dimension feature information can refer to a subset of data selected from multi-dimensional feature information that can uniquely distinguish different vehicle individuals or time attributes. In this embodiment, the target dimension feature information may include, but is not limited to: the country of manufacture code, manufacturer code, and year code in the vehicle identification number (VIN), the complete vehicle model code, and the year, month, day, week, and quarter information obtained by parsing the vehicle's entry date. Differences in the VIN and entry date of different vehicles result in different target dimension feature information for different vehicles. This difference ensures that even if the vehicle model code is the same, as long as the VIN or entry date is different, the generated target dimension feature information will be different, thereby guaranteeing the uniqueness and security of key derivation.

[0041] In this embodiment, after obtaining the vehicle's identification information and lifecycle information from the vehicle-to-everything (V2X) terminal data to be stored, multi-dimensional feature information associated with the vehicle can be extracted from the identification information and lifecycle information, respectively. This embodiment aims to perform deep analysis and feature extraction on the obtained identification information and lifecycle information to construct multi-dimensional feature information for key derivation.

[0042] Optionally, during the extraction of multi-dimensional feature information from the identification information, feature extraction is performed on the vehicle's identification information. During feature extraction, the VIN can be parsed in multiple dimensions to extract the country of manufacture code, manufacturer code, and year code as key features; the complete vehicle model code is retained as another key feature. The data extracted from the VIN and vehicle model code constitute the identity dimension of the multi-dimensional feature information. Since each vehicle's vehicle identification number and vehicle model code are unique, the extracted identity dimension feature information will inevitably differ between different vehicles, ensuring the uniqueness of the feature information.

[0043] Optionally, during the extraction of multi-dimensional feature information from the lifecycle information, a time dimension parsing operation is performed on the vehicle's lifecycle information, namely the vehicle's entry date. The vehicle entry date is parsed into multiple time dimension data, including year, month, day, weekday, and quarter information. For example, the year is converted to a two-digit representation, the month is converted to numbers and English abbreviations, the date is converted to numbers and weekday attributes, and the corresponding quarter is calculated. The time dimension data obtained from the vehicle entry date constitutes the time dimension portion of the multi-dimensional feature information. Because different vehicles have different entry dates, the parsed time dimension data differs, further enhancing the variability and randomness of the multi-dimensional feature information.

[0044] In this embodiment, the method described above achieves deep fusion of identity features and time features by extracting multi-dimensional feature information from identification information and lifecycle information respectively. This multi-source feature extraction not only preserves the unique identifier of the vehicle but also introduces the changing factor of the time dimension. Different vehicles have different target dimension feature information, ensuring that the generated key has high uniqueness and unpredictability, effectively solving the security risk of "one key for multiple vehicles" in traditional solutions.

[0045] Step S206: Utilize multi-dimensional feature information to generate a key for vehicle network terminal data.

[0046] In the technical solution provided in step S206 of this application embodiment, the aforementioned key can refer to a high-strength symmetric key dynamically generated by a cryptographic algorithm based on the multi-dimensional feature information, used for encrypting and decrypting data of the vehicle network terminal. This key can also be called an enhanced key. In this application embodiment, the enhanced key can be represented as a 256-bit Advanced Encryption Standard (AES) key, with strength meeting the security requirements of the AES standard. This key is not a pre-stored or statically allocated fixed key, but rather is derived in real-time based on the unique multi-dimensional feature information of each vehicle.

[0047] In this embodiment, after extracting multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively, a key for vehicle-to-everything (V2X) terminal data can be generated using this multi-dimensional feature information. This embodiment aims to use the previously extracted multi-dimensional feature information to generate a key for encrypting V2X terminal data through a specific cryptographic algorithm (e.g., a key derivation algorithm). The above process can be a step in converting multi-dimensional feature information into a cryptographically strong secure key. For example, by introducing parameters such as salt and iteration count, the generated 256-bit AES key can be ensured to have high randomness, uniqueness, and resistance to brute-force attacks, thereby achieving independent encryption protection for specific vehicle data.

[0048] Optionally, during the key generation process using multi-dimensional feature information, the multi-dimensional feature information can be preprocessed and standardized. This preprocessed and standardized multi-dimensional feature information is then used as the input cryptographic material for the key derivation algorithm. A salt value is then introduced. This salt value increases the randomness entropy source in key generation and ensures consistency of the salt value under the same input conditions. The Password-Based KeyDerivation Function 2 with HMAC-SHA256 (PBKDF2WithHmacSHA256) is called, using the processed multi-dimensional feature information as the input parameter for key derivation and the aforementioned salt value as the salt input. At least 100,000 iterations are set to resist brute-force attacks. The output length is specified as 32 bytes (256 bits). After multiple hash operations and obfuscations using the PBKDF2 algorithm, a 256-bit AES enhanced key is finally generated. This generated 256-bit AES enhanced key can be used as the final key. The aforementioned key is generated only in memory and used for subsequent encryption operations. If it is not used immediately after generation, it can be cleared to avoid the risk of leakage caused by persistent storage.

[0049] In this embodiment, the method described above generates an enhanced key by utilizing multi-dimensional feature information combined with the PBKDF2 algorithm, thus transforming it from a "management key" to a "derived key." This approach eliminates the need to store the plaintext key in a database, mitigating the risk of large-scale data leakage due to a compromised key storage center. Furthermore, because the multi-dimensional feature information differs between vehicles, the generated enhanced key is unique, achieving "one key per vehicle" security isolation. Even if the key of one vehicle is cracked, the security of the vehicle network terminal data of other vehicles will not be affected.

[0050] Step S208: Encrypt the vehicle network terminal data according to the key, and store the encrypted vehicle network terminal data.

[0051] In the technical solution provided in step S208 of this application embodiment, after generating a key for vehicle network terminal data using multi-dimensional feature information, the vehicle network terminal data can be encrypted according to the key. The encrypted vehicle network terminal data can then be stored.

[0052] Optionally, during the encryption of vehicle-to-everything (V2X) terminal data using the key, the Advanced Encryption Standard - Galois / Counter Mode (AES-GCM) encryption algorithm can be employed. The key for encrypting the V2X terminal data can be obtained from the generated 256-bit enhancement key. A 12-byte initialization vector (IV) is generated, which ensures that the same plaintext produces different ciphertexts in different encryption operations, preventing replay attacks. Sensitive fields from the V2X terminal data to be stored (e.g., the complete 17-bit vehicle identification number) are used as plaintext input, combined with the enhancement key and the IV, and encrypted using the AES-GCM algorithm. This algorithm provides confidentiality protection while incorporating a built-in Message Authentication Code (MAC) mechanism to generate an authentication tag bound to the ciphertext, used to verify whether the ciphertext has been tampered with during transmission or storage. The final output is an encrypted result packet containing the ciphertext data and the authentication tag.

[0053] Optionally, during the storage of encrypted vehicle-to-everything (V2X) terminal data, the ciphertext data generated by the encryption operation, the authentication tag, the random initialization vector, and the currently used encryption algorithm version information can be encapsulated into a single vehicle encryption record. This encrypted record can then be used as the stored data of the V2X terminal. The encrypted record is stored in a vehicle encryption record table in the cloud database. This vehicle encryption record table may include fields such as a vehicle identifier (ID) primary key, encrypted vehicle identification code, plaintext vehicle model code, plaintext entry date, encryption algorithm version, and encryption timestamp. By storing the encryption algorithm version, it ensures compatibility with the decryption requirements of older data in the event of future algorithm upgrades or changes. The encrypted vehicle identification code can consist of ciphertext and an initialization vector. Since all stored V2X terminal data exists in ciphertext form, even if the files in the cloud server's database are illegally accessed, attackers cannot directly reconstruct the original V2X terminal data from these files, thus ensuring the security of the static storage of V2X terminal data.

[0054] In this embodiment, the method employs AES-GCM encryption and storage to achieve dual protection of data confidentiality and integrity. The encrypted vehicle-to-everything (V2X) terminal data is stored in ciphertext, effectively preventing the risk of sensitive information exposure due to database leaks. Simultaneously, the built-in authentication tag mechanism of AES-GCM ensures data integrity during storage and retrieval; any tampering with the ciphertext will be detected and rejected during the decryption process.

[0055] In steps S202 to S208 of this embodiment, if vehicle network terminal data that needs to be stored is detected, the vehicle's identification information and lifecycle information can be obtained from the vehicle network terminal data. Multi-dimensional feature information associated with the vehicle can be extracted from the identification information and lifecycle information. This multi-dimensional feature information can be used to generate a key for the vehicle network terminal data. The vehicle network terminal data can be encrypted using the key, and the encrypted data can be stored. In other words, in this embodiment, by extracting multi-dimensional features from the vehicle's identification information and lifecycle information and dynamically generating a key, "one key per vehicle" is achieved, avoiding the risk of exposing a large amount of vehicle network terminal data due to the leakage of fixed keys. This method does not rely on expensive hardware or external KMS services, eliminating network dependence, single points of failure, and high maintenance costs. It effectively avoids the shortcomings of related technologies in terms of security, scalability, and low latency, thereby improving the technical effect of vehicle data processing and solving the technical problem of poor vehicle data processing performance.

[0056] The embodiments of this application will be described in detail below with reference to the steps described above.

[0057] As an optional implementation, step S206, which uses multi-dimensional feature information to generate a key for encrypting vehicle network terminal data, includes: mixing multi-dimensional feature information to obtain mixed feature information; and using the mixed feature information to generate a key.

[0058] In this embodiment, during the process of generating a key for encrypting vehicle network terminal data using multi-dimensional feature information, the multi-dimensional feature information can be mixed to obtain hybrid feature information. This hybrid feature information can then be used to generate the key. Specifically, the hybrid feature information refers to a standardized input sequence formed by structurally recombining, cross-combining, and numerically converting vehicle identification number (VIN) feature data, vehicle model code data, and vehicle entry date parsing data. This hybrid feature information serves as the cryptographic input material for the cryptographic key derivation function 2 during the key derivation process. This hybrid feature information can also be referred to as enhancement material or cryptographic material.

[0059] Optionally, in the process of mixing multi-dimensional feature information to obtain hybrid feature information, vehicle identification number (VIN) feature data, vehicle model code data, and vehicle entry date parsing data can be extracted. The VIN feature data includes the last six characters of the VIN, the first character of the VIN's country of manufacture code, and the VIN's manufacturer code; the vehicle model code data includes a complete six-digit vehicle model identifier code; and the vehicle entry date parsing data includes the year, month, quarter, and weekday information. The extracted data undergoes interleaving and transformation processing. Interleaving refers to swapping the positions of characters in the VIN feature data and numbers in the vehicle entry date parsing data according to a predetermined algorithm; transformation refers to performing non-linear character mapping or shifting on the vehicle model code data. The processed data is combined, and a version prefix and suffix are added to form hybrid feature information. This hybrid feature information undergoes standardization to ensure a fixed input data format, eliminate the regularity of the original business data, and increase the randomness entropy value of the data, serving as cryptographic input material for a key derivation function based on cryptography.

[0060] Optionally, during the key generation process using the mixed feature information, a salt value can be obtained. The salt value is 16 bytes long and is generated from a preset global salt using a hash algorithm. The mixed feature information is used as the password input, and the global salt value is used as the salt input. The iteration count is set to one million, and the output key length is set to 128 bytes. The password-based key derivation function 2 algorithm is called, specifying the hash algorithm as a combination of a hash message authentication code and a 256-bit secure hash algorithm. The algorithm performs iterative operations, mixing the password input with the salt value. After one million iterations, it outputs 128 bytes of key material. This key material is the enhanced key used to encrypt data in the vehicle networking terminal. This key is generated and used only in memory and is immediately deleted after use; it is not included in persistent storage, ensuring that the key cannot be leaked through storage media.

[0061] In this embodiment, the method transforms simple business data into cryptographically strong input material through the hybrid processing of multi-dimensional feature information, eliminating the inherent linearity of business data and enhancing the randomness and unpredictability of key generation. By utilizing a cryptographically based key derivation function 2 algorithm combined with a high number of iterations, the computational cost of brute-force attacks is further increased, significantly improving key security. This scheme eliminates the need for key storage; keys are dynamically derived through business features and a deterministic algorithm, solving the storage security risks and distribution challenges of traditional key management. It achieves a "one vehicle, one key" security strategy while avoiding the network dependence and high costs associated with key management systems, ensuring the confidentiality and integrity of vehicle network data during storage and use.

[0062] As an optional implementation, the multi-dimensional feature information includes vehicle identification features, vehicle type features, and temporal features. The vehicle identification feature is used to represent the vehicle's identity, the vehicle type feature is used to represent the vehicle's configuration attributes, and the temporal feature is used to represent the vehicle's entry time. The multi-dimensional feature information is mixed to obtain mixed feature information, including: interleaving the temporal feature into the vehicle identification feature to obtain initial mixed feature information, wherein the initial mixed feature information is obtained by mixing the temporal feature and the vehicle identification feature; deforming the vehicle type feature, and inserting the deformed vehicle type feature into the initial mixed feature information to obtain mixed feature information.

[0063] In this embodiment, during the process of mixing multi-dimensional feature information to obtain mixed feature information, temporal features can be added and inserted into the vehicle representation features to obtain initial mixed feature information. Vehicle type features can be deformed, and the deformed vehicle type features can be inserted into the initial mixed feature information to obtain mixed feature information.

[0064] The vehicle identification feature refers to the structured data set extracted from the vehicle identification code (VIC) used to determine the vehicle's identity. This feature may include the last six characters of the VIC, the first character of the VIC's country of manufacture code, and the VIC's manufacturer code. The vehicle type feature refers to the structured data set extracted from the vehicle model code used to represent vehicle configuration attributes. This feature may include a complete six-digit vehicle model identification code. This vehicle type feature is used to distinguish different vehicle model configurations, ensuring that vehicles of the same model have the same feature base during key derivation, thereby supporting a vehicle model-based key management strategy.

[0065] Optionally, the aforementioned time-series feature can refer to a multi-dimensional data set extracted from the vehicle's entry date to represent its time attributes. This time-series feature may include the year, month, quarter, and weekday information of the vehicle's entry date. This feature introduces variability in the time dimension, increases the entropy of the key derivation input, and prevents key regularity caused by static vehicle features.

[0066] Optionally, the aforementioned interleaving insertion can refer to the process of exchanging and mixing data elements in the time-series features with data elements in the vehicle identification features according to a predetermined algorithm. This interleaving insertion process aims to break the original linear arrangement of the vehicle identification features and time-series features, eliminate inherent patterns in the data, and generate initial mixed feature information, thereby increasing the randomness and complexity of the input data. The aforementioned transformation processing can refer to the preprocessing process of performing nonlinear mapping or shifting operations on the character sequences in the vehicle type features. This transformation processing aims to change the original character structure of the vehicle type features, preventing attackers from directly deriving the key through simple string concatenation or known vehicle model code features, and enhancing the obfuscation level of the key-derived input.

[0067] Optionally, during the process of interleaving temporal features into vehicle identification features to obtain initial mixed feature information, character sequences can be extracted from the vehicle identification features. These character sequences may include the last six characters of the vehicle identification code, the first character of the vehicle identification code (country of manufacture code), and the vehicle identification code (manufacturer code). Simultaneously, numerical sequences can be extracted from the temporal features. These numerical sequences may include year, month, quarter, and day of the week information. Following a predetermined algorithm, elements from the numerical sequences of the temporal features are sequentially inserted into specified gaps in the character sequences of the vehicle identification features. For example, year or month numbers are interleaved between each character of the last six characters of the vehicle identification code. Through this positional exchange and mixing operation, the independent arrangement order of the vehicle identification features and temporal features is broken, eliminating inherent patterns in the data, thereby generating initial mixed feature information. This initial mixed feature information integrates vehicle identification and time attributes, increasing the randomness entropy value of the data.

[0068] Optionally, during the transformation process of vehicle type features, nonlinear mapping or shift operations can be performed on the character sequences in the vehicle type features. The nonlinear mapping operation refers to replacing specific characters in the vehicle type features with corresponding mapped characters according to predetermined rules. The shift operation refers to performing a global or partial cyclic shift on the character sequences in the vehicle type features. Through these transformation processes, the original character arrangement structure and character content of the vehicle type features are changed, preventing attackers from directly deriving the key using known vehicle model code features. The transformed vehicle type features retain the semantic information of the vehicle model configuration attributes but eliminate their original predictability, providing obfuscated data for subsequent mixing.

[0069] Optionally, during the process of inserting the deformed vehicle type features into the initial mixed feature information to obtain the mixed feature information, the aforementioned generated initial mixed feature information and the deformed vehicle type features can be obtained. The character sequence of the deformed vehicle type features is inserted into the sequence of the initial mixed feature information at a predetermined insertion position. This insertion position can be at the beginning, end, or a specific gap in the middle of the initial mixed feature information. Through this insertion operation, vehicle configuration attribute information is deeply integrated into the initial mixed feature information containing identity and time attributes. After insertion, the resulting complete data sequence is the mixed feature information.

[0070] In this embodiment, the method effectively breaks the linear correlation between time data and identity data by interleaving temporal features and vehicle identification features, eliminating the regularity of data arrangement and significantly improving the randomness entropy value of the input data. By deforming the vehicle type features, the original structure of the vehicle model code is changed, preventing key deduction attacks based on known vehicle model features. Inserting the deformed vehicle type features into the initial mixed feature information achieves deep coupling and obfuscation of multi-dimensional business features.

[0071] As an optional implementation, generating a key using hybrid feature information includes: adding the version prefix and version suffix of the key derivation model to the hybrid feature information to obtain the hybrid feature information after addition; generating a hash value based on the hybrid feature information after addition and the salt value using the key derivation model; and generating a key using the hash value.

[0072] In this embodiment, during the key generation process using hybrid feature information, the version prefix and suffix of the key derivation model can be added to the hybrid feature information to obtain the added hybrid feature information. A hash value can then be generated using the key derivation model based on the added hybrid feature information and the salt value. The key can then be generated using this hash value.

[0073] The aforementioned key derivation model can be a key derivation algorithm, such as the Password-Based Key Derivation Function 2 (PBKDF2) algorithm, or a 256-bit hash message authentication code combined with a secure hash algorithm. This key derivation model takes mixed feature information, salt value, number of iterations, and key length as input parameters. Through intensive iterative computation, it transforms low-entropy input material into high-entropy fixed-length key material. This key derivation model ensures the determinism, one-wayness, and resistance to brute-force attacks in key generation.

[0074] Optionally, the version prefix of the aforementioned key derivation model can refer to a prefix string added to the header of the hybrid feature information. This prefix string may contain a version identifier of the key derivation algorithm. The version prefix can be used to identify the algorithm version and parameter configuration used in the current key derivation, ensuring that different versions of the key derivation process are distinguishable during algorithm iteration or upgrades, preventing key generation errors caused by algorithm version confusion. The version suffix of the aforementioned key derivation model can refer to a suffix string added to the tail of the hybrid feature information. This suffix string may contain a version identifier of the key derivation algorithm. The version suffix and version prefix together constitute the version marker of the key derivation model, used to enhance the structural integrity of the hybrid feature information.

[0075] Optionally, the salt value mentioned above can refer to deterministic random data of 16 bytes in length. This salt value can be generated by hashing a global salt value. The salt value, along with mixed feature information, is input into the key derivation model to eliminate the risk of the same password input generating the same key, preventing rainbow table attacks. The determinism of the salt value ensures consistency of the salt values ​​generated under the same business conditions, thereby guaranteeing the reproducibility of key generation. The hash value mentioned above can refer to the intermediate or final data result output by the key derivation model after a specified number of iterations. This hash value is 128 bytes long and possesses a one-way characteristic of cryptographic strength.

[0076] Optionally, during the process of adding a version prefix and a version suffix to the hybrid feature information to obtain the hybrid feature information, the version prefix of the key derivation model is obtained, and the version suffix of the key derivation model is obtained. The version prefix is ​​concatenated to the beginning of the hybrid feature information, and the version suffix is ​​concatenated to the end of the hybrid feature information. The above concatenation operation of the version prefix and version suffix ensures that the input hybrid feature information has clear structural boundaries and version identification, preventing key generation errors caused by inconsistent input data formats or confused algorithm versions. After concatenation, the resulting complete data sequence containing the version identification and the original hybrid feature information is the hybrid feature information after addition.

[0077] Optionally, during the process of generating a hash value using the key derivation model based on the added mixed feature information and salt value, the added mixed feature information, salt value, and preset key derivation parameters can be obtained. These preset key derivation parameters may include the number of iterations and the hash algorithm type. The number of iterations is set to one million, and the hash algorithm type is set to a 256-bit hash message authentication code combined with a secure hash algorithm. The added mixed feature information is used as the password input, and the salt value is used as the salt input, both input to the key derivation model. The key derivation model performs a specified number of iterations, mixing the output of the previous operation with the password input and salt value in each iteration. After one million iterations, the key derivation model outputs a fixed-length data result. This data result is then determined as the hash value.

[0078] Optionally, during the key generation process using the hash value, the generated hash value can be obtained. A data segment of a specified length is extracted from the hash value, where the specified length is consistent with the key length required by the encryption algorithm, for example, 256 bits (32 bytes). The first 32 bytes of the hash value are used as the final key for generating encrypted vehicle network terminal data.

[0079] In this embodiment, the method described above achieves version control and data encapsulation standardization in the key derivation process by adding version prefixes and suffixes. This ensures compatibility and traceability between different versions of the key derivation algorithm, avoiding key generation chaos caused by algorithm upgrades. The method eliminates the need to store fixed keys; instead, it dynamically generates high-strength keys through a deterministic algorithm process, implementing a "one vehicle, one key" security strategy. This balances security, performance, and maintainability, effectively guaranteeing the secure storage and transmission of vehicle network data.

[0080] As an optional implementation, a hash value is generated using a key derivation model based on the added mixed feature information and the salt value. This includes: in response to the current iteration being the first iteration, using the key derivation model, generating the hash value for the first iteration based on the added mixed feature information and the initial salt value in the first iteration; and in response to the existence of a previous iteration and a next iteration in the current iteration, using the key derivation model, determining the hash value of the previous iteration as the salt value for the current iteration, and generating the hash value for the current iteration based on the added mixed feature information and the salt value for the current iteration, and incrementing the iteration count by one.

[0081] In this embodiment, during the process of generating a hash value using a key derivation model based on the mixed feature information and the salt value, if the current iteration is the first iteration, the key derivation model can be used to generate the hash value of the first iteration based on the mixed feature information and the initial salt value. If the current iteration has a previous iteration and a next iteration, the key derivation model can be used to determine the hash value of the previous iteration as the salt value of the current iteration, and the hash value of the current iteration can be generated based on the added mixed feature information and the salt value of the current iteration, and the iteration count can be incremented by one.

[0082] The first iteration refers to the first computation cycle in the iterative operation process of the key derivation model. In the first iteration, input parameters may include the added mixed feature information and the initial salt value. The first iteration initializes the key derivation process by performing the initial mixed operation on the original business features and the deterministic salt value, generating the basic hash result for subsequent iterations. The initial salt value can refer to the salt value data used in the first iteration operation, calculated from the global salt value using a hash algorithm. The initial salt value provides initial randomness at the beginning of the key derivation process, ensuring that the same mixed feature information can generate different first-iteration hash values ​​under different global salt values ​​or different initialization conditions, thereby preventing pre-computation attacks and rainbow table attacks.

[0083] Optionally, determine if the current iteration is the first iteration. If it is, obtain the added mixed feature information and the initial salt value. The initial salt value is a fixed-length data generated by hashing the global salt value. Use the added mixed feature information as the password input and the initial salt value as the salt input, and input them into the key derivation model. The key derivation model performs a single hash operation, mixing the password input and the initial salt value to generate the hash value for the first iteration. Optionally, during intermediate iterations other than the first and last iterations, determine if the current iteration count is greater than the first iteration and less than the preset total number of iterations. If the condition is met, obtain the hash value generated in the previous iteration. Use the hash value from the previous iteration as the salt value for the current iteration. Obtain the added mixed feature information. Use the added mixed feature information as the password input and the salt value for the current iteration as the salt input, and input them into the key derivation model. The key derivation model performs a hash operation to generate the hash value for the current iteration. Increment the iteration counter to update the current iteration count. Repeat the above steps until the iteration count reaches the preset total number of iterations. By using the previous result as the new salt value in each iteration, deep data obfuscation and iterative accumulation are achieved, significantly increasing the computational complexity of brute-force attacks.

[0084] In this embodiment, the method initializes the key derivation process in the first iteration, ensuring the determinism and initial randomness of the input data. Through intermediate iterations, the hash value of the previous iteration is used as the salt value for the current iteration, forming a chain-dependent structure. This ensures that the final output hash value depends on the calculation results of all intermediate iterations. This iterative mechanism significantly increases the computational cost of key generation, effectively resisting brute-force attacks and rainbow table attacks. Simultaneously, this iterative process is entirely based on a deterministic algorithm, ensuring that the same key can be reproduced under the same input conditions, meeting the key generation consistency requirements in vehicle-to-everything (V2X) services, thus achieving high-strength data security protection without the need to store the key.

[0085] As an optional implementation, a key is generated using a hash value, including: determining the hash value of the current iteration as the salt value for the next iteration, determining the next iteration as the current iteration, and repeating the generation steps until the number of iterations equals an iteration number threshold, and generating a key that meets a preset key length based on the hash value of the iteration number threshold.

[0086] In this embodiment, during the key generation process using hash values, the hash value of the current iteration can be determined as the salt value for the next iteration. The next iteration can be determined as the current iteration, and the above generation steps are repeated until the number of iterations equals an iteration threshold. Based on the hash value of the iteration threshold, a key satisfying a preset key length can be generated. The iteration threshold refers to the upper limit of the total number of iterations performed by the key derivation model. This iteration threshold is set to one million times, aiming to improve the security of key generation by increasing computational complexity. A higher iteration threshold increases the time cost required for attackers to perform brute-force or rainbow table attacks, thus effectively resisting offline cracking attacks. Simultaneously, this threshold needs to strike a balance between security and system performance. The preset key length refers to the byte length of the final generated key. This preset key length is set to thirty-two bytes (i.e., 256 bits) to match the key length requirement of Advanced Encryption Standards (AES-256) at 256 bits. The preset key length determines the entropy value of the output key. The 256-bit key length provides extremely high security strength, which can resist current computing power attacks and ensure the confidentiality of vehicle network data transmission and storage.

[0087] Optionally, during the iterative process until the final key is generated, it can be determined whether the current iteration number is equal to a preset iteration threshold. If the current iteration number is less than the preset threshold, an iterative update operation is performed. The hash value generated in the current iteration is determined as the salt value for the next iteration. The sequence number of the next iteration is updated to the current iteration, i.e., the current iteration counter is incremented by one. Using the updated current iteration, the added mixed feature information, and the newly determined salt value, the generation steps are repeated to generate a new hash value. The above judgment and update operations are repeated until the current iteration number equals the preset iteration threshold. Through this chain-like iterative mechanism, the final output hash value depends on the calculation results of each preceding iteration step, greatly increasing computational complexity and security.

[0088] Optionally, during the process of generating a key that meets the preset key length based on the hash value of the iteration number threshold, if the current iteration number is equal to the preset iteration number threshold, the hash value generated in the current iteration is obtained. This hash value is the final data result output after the operation of the preset iteration number threshold. A data segment of a specified length is extracted from this final hash value. This specified length is consistent with the preset key length, for example, thirty-two bytes. The extracted data segment is the final key that meets the preset key length. This final key is used for subsequent encryption operations on vehicle data to ensure the secure storage and transmission of data. The final key is generated and used in memory, and is immediately cleared after use, without being persistently stored.

[0089] In this embodiment, the method iterates repeatedly until an iteration threshold is reached, ensuring that the key derivation process fully integrates all features of the input data and random salt value, eliminating the linearity of the input data, and significantly improving the randomness and anti-cracking capability of the key. Generating a key based on the final hash value of the iteration threshold ensures the determinism and consistency of key generation, enabling the reproduction of the same key under the same input conditions, thus meeting the dynamic key generation requirements in vehicle-to-everything (V2X) services. Truncation to a preset key length ensures that the generated key meets the strength requirements of advanced encryption standards, guaranteeing both security and compatibility with encryption algorithms, achieving a balance between high security, high performance, and low storage cost.

[0090] As an optional implementation, step S202, obtaining vehicle identification information from the vehicle network terminal data to be stored, includes: verifying the vehicle network terminal data to be stored and obtaining a verification result; and extracting identification information from the vehicle network terminal data that the verification result indicates has authenticity and integrity.

[0091] In this embodiment, during the process of obtaining vehicle identification information from the vehicle-to-everything (V2X) terminal data to be stored, the V2X terminal data to be stored can be verified to obtain a verification result. Identification information can be extracted from the V2X terminal data that the verification result indicates has authenticity and integrity. The verification result can refer to the judgment status output after performing integrity verification and identity authentication on the V2X terminal data. The verification result can include the final conclusions regarding whether the V2X terminal data has passed signature verification, whether the data format is compliant, and whether the data has not been tampered with. A verification result of "pass" indicates that the data meets the reception standards and is qualified to enter the subsequent encryption processing flow; a verification result of "fail" indicates that the data is abnormal and needs to be discarded or reported to the anomaly log.

[0092] The aforementioned authenticity refers to the attribute that the vehicle-to-everything (V2X) terminal data originates from legitimate and authorized vehicle terminal equipment. Data authenticity means that the V2X terminal data was indeed generated by the vehicle's V2X terminal equipment, and not injected by counterfeit devices or man-in-the-middle attackers. Ensuring authenticity relies on the effective verification of the digital signature or message authentication code of the V2X terminal data to ensure the data source is trustworthy and prevent unauthorized devices from accessing the network and reporting false data. The aforementioned integrity refers to the attribute that the V2X terminal data has not been illegally modified, inserted, deleted, or replayed during transmission.

[0093] Optionally, in the process of verifying the authenticity and integrity of vehicle-to-everything (V2X) terminal data, the V2X terminal data to be stored can be obtained. This V2X terminal data may include a business data payload and an accompanying digital signature or message authentication code. The digital signature or message authentication code is extracted from the V2X terminal data. Using a preset public key or shared key, the content of the V2X terminal data is verified to generate a verification value. The generated verification value is compared with the digital signature or message authentication code carried in the V2X terminal data. If they match, the V2X terminal data is deemed authentic, meaning the data originates from a legitimate sender; if they do not match, the V2X terminal data is deemed illegitimate. Simultaneously, a hash value or checksum is calculated for the business payload portion of the V2X terminal data and compared with the integrity protection value carried in the data. If they match, the V2X terminal data is deemed intact, meaning the data has not been tampered with during transmission; if they do not match, the V2X terminal data is deemed incomplete. A verification result is generated by combining the authenticity and integrity determination results. If both authenticity and completeness are deemed to pass, the verification result indicates that the data possesses both authenticity and completeness.

[0094] Optionally, during the extraction of identification information from vehicular network terminal data that possesses authenticity and completeness, a verification result can be obtained. The verification result is then used to determine whether the data possesses authenticity and completeness. If the verification result indicates authenticity and completeness, vehicle identification information is parsed from the vehicular network terminal data. Vehicle identification information includes the Vehicle Identification Number (VIN). The VIN field is located within the data structure of the vehicular network terminal data. The numerical content of the VIN field is extracted. If the verification result does not indicate authenticity and completeness, the vehicular network terminal data is discarded, and vehicle identification information is not extracted. The extracted VIN serves as one of the input features for the subsequent key derivation model.

[0095] In this embodiment, by verifying the vehicle-to-everything (V2X) terminal data to be stored, forged data reported by illegal devices and corrupted data tampered with during transmission are effectively filtered out, ensuring the quality and security of cloud-stored data from the source. Identification information is extracted only from vehicular terminal data that possesses authenticity and integrity, ensuring the accuracy and reliability of the business data upon which subsequent key derivation and encryption processes are based, avoiding key generation failures or decryption anomalies due to data errors. This mechanism enhances the security defense capabilities of the V2X data link, preventing malicious attackers from interfering with the key management process by injecting false data, and improving the robustness and reliability of the overall data protection system.

[0096] As an optional implementation, the vehicle-to-everything (V2X) terminal data to be stored is verified to obtain a verification result, including: verifying the V2X terminal data to be stored using the data signature of the V2X terminal data to obtain a first verification result, wherein the data signature is used to indicate the authenticity of the vehicle from which the V2X terminal data originates, and the first verification result is used to indicate whether the V2X terminal data to be stored is authentic; comparing the hash value contained in the V2X terminal data to be stored with the hash value calculated based on the V2X terminal data to obtain a comparison result; and verifying the V2X terminal data to be stored based on the comparison result to obtain a second verification result, wherein the second verification result is used to indicate whether the V2X terminal data to be stored is complete.

[0097] In this embodiment, during the verification of the vehicle-to-everything (V2X) terminal data to be stored and the obtaining of the verification result, the data signature of the V2X terminal data to be stored can be used to verify the V2X terminal data to be stored, obtaining a first verification result. The hash value contained in the V2X terminal data to be stored can be compared with the hash value calculated based on the V2X terminal data to obtain a comparison result. Based on the above comparison result, the V2X terminal data to be stored can be verified to obtain a second verification result.

[0098] The aforementioned data signature refers to the encrypted string generated by the vehicle-to-everything (V2X) terminal device after digitally signing the V2X terminal data using its own private key. This data signature can be used to prove the source identity of the V2X terminal data and verify whether the data was generated by a legitimate vehicle terminal device holding the corresponding private key. The aforementioned first verification result refers to the conclusion regarding the authenticity of the V2X terminal data obtained by verifying the validity of the data signature. The first verification result indicates whether the V2X terminal data to be stored is authentic. If the data signature verification passes, the first verification result indicates that the V2X terminal data originates from a legitimate intended sender and possesses authenticity; if the data signature verification fails, the first verification result indicates that the V2X terminal data may originate from an illegal entity or have been tampered with, and therefore lacks authenticity.

[0099] Optionally, the aforementioned comparison result may refer to the matching status obtained by comparing the hash value carried in the vehicle-to-everything (V2X) terminal data with the hash value recalculated by the receiving end based on the received V2X terminal data. The comparison result is used to reflect whether the V2X terminal data maintains its original state during transmission. If the hash value carried in the V2X terminal data matches the hash value calculated based on the V2X terminal data, the comparison result indicates a match; if they do not match, the comparison result indicates a mismatch. The aforementioned second verification result may refer to the judgment conclusion on the integrity of the V2X terminal data based on the comparison result. The second verification result is used to indicate whether the V2X terminal to be stored has integrity. If the comparison result shows a match, the second verification result indicates that the V2X terminal data has not been illegally modified, inserted, or deleted during transmission and has integrity; if the comparison result shows a mismatch, the second verification result indicates that the V2X terminal data may have been tampered with or damaged and does not have integrity.

[0100] Optionally, during the verification of the authenticity of the vehicle-to-everything (V2X) terminal data, the V2X terminal data to be stored is obtained. This data includes the business data payload and an associated data signature. The data signature is extracted; this data signature is generated by the sending vehicle using a private key and is used to identify the authenticity of the sending vehicle's identity. A public key or shared key for verifying the data signature is obtained, and this key is paired with the sending vehicle's private key. Using the extracted data signature and the obtained key, a signature verification algorithm is executed on the business data payload of the V2X terminal data. The signature verification algorithm compares the recalculated data digest with the digest information in the data signature. If the comparison matches, the data signature is deemed valid, and the first verification result indicates that the V2X terminal data to be stored is authentic, i.e., the data source is trustworthy; if the comparison does not match, the data signature is deemed invalid, and the first verification result indicates that the V2X terminal data to be stored is not authentic, i.e., the data may originate from an illegal entity or has been tampered with.

[0101] Optionally, during the process of verifying the integrity of the vehicle-to-everything (V2X) terminal data, the V2X terminal data to be stored is obtained. This data includes a service data payload and an embedded hash value. The hash value contained in the V2X terminal data is extracted. This hash value is calculated by the sender from the service data payload before transmission. The service data payload portion of the V2X terminal data is recalculated using the same hash algorithm to obtain a hash value calculated based on the V2X terminal data. The hash value contained in the V2X terminal data is compared with the hash value calculated based on the V2X terminal data to obtain a comparison result. If the two hash values ​​are completely identical, the comparison result indicates a match, and the second verification result indicates that the V2X terminal to be stored has integrity, that is, the data has not been modified during transmission. If the two hash values ​​are inconsistent, the comparison result indicates a mismatch, and the second verification result indicates that the V2X terminal to be stored does not have integrity, that is, the data has been changed or damaged during transmission.

[0102] In this embodiment, the method utilizes data signatures to verify the authenticity of vehicle network terminal data, effectively preventing unauthorized devices from accessing the network and reporting false data. This ensures that the data source for cloud processing originates from legitimate, intended vehicles, enhancing the system's security access control capabilities. By comparing hash values ​​to verify the integrity of vehicle network terminal data, it effectively detects potential tampering, loss, or errors in the data transmission link, guaranteeing the accuracy and consistency of business data. This dual verification mechanism forms a complementary security protection system, safeguarding both the legitimate identity of the data source and the original state of the data content. This provides a highly reliable data foundation for subsequent key derivation and encrypted storage, significantly reducing security risks and business anomalies caused by data forgery or corruption.

[0103] This embodiment provides another method for vehicle data processing. Figure 3 This is a flowchart of another vehicle data processing method according to an embodiment of this application, such as... Figure 3 As shown, this method is applied to a cloud server and may include the following steps.

[0104] In step S302, in response to obtaining the vehicle network terminal data to be stored, the vehicle identification information and the vehicle lifecycle information are obtained from the vehicle network terminal data.

[0105] Step S304: Extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information respectively.

[0106] In the technical solution provided by step S304 in the embodiments of this application, the multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles.

[0107] Step S306: Using multi-dimensional feature information, generate a key for encrypting vehicle network terminal data.

[0108] Step S308: Encrypt the data of the vehicle network terminal according to the key.

[0109] Step S310 involves storing the encrypted vehicle network terminal data in the database of the cloud server.

[0110] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.

[0111] With the explosive growth in the number of connected vehicle devices (estimated to reach billions by 2030), secure data storage and usage necessitate encryption and key management of critical data. Traditional key management solutions face insurmountable scalability challenges. Enhanced key derivation schemes represent a paradigm shift from "managing keys" to "deriving keys," potentially representing a crucial direction for future IoT security. For connected vehicle companies seeking long-term security, scalability, and cost control, enhanced key derivation schemes offer the optimal balance under current technological conditions.

[0112] In existing technologies, vehicle data encryption and decryption mainly employ the following methods: traditional symmetric encryption with fixed keys, and Key Management Systems (KMS). Traditional symmetric encryption with fixed keys typically uses the same key for both encryption and decryption, with common algorithms including AES and DES. In connected vehicle scenarios, traditional symmetric encryption is generally implemented as follows: during system initialization, one or more fixed symmetric keys (such as AES-256 keys) are generated. These keys are stored in configuration files, databases, or environment variables, and are usually subjected to secondary encryption (such as using a master key) to enhance security. When vehicles report data, the cloud uses a preset symmetric key to encrypt sensitive data such as the VIN. Business systems then need to use the same key to decrypt the encrypted data.

[0113] For a Key Management System (KMS), the aforementioned KMS can be a centralized key management service, providing full lifecycle management of keys, including generation, storage, rotation, and destruction. Typically, this is implemented as follows: the KMS generates a unique key for each vehicle (or uses a hierarchical key structure) and securely stores it in an HSM (Hardware Storage System) or encrypted storage. The Master Key is usually stored in the HSM and used to encrypt the Data Key. When vehicle data is reported, the cloud requests the encryption key from the KMS (or directly uses the KMS encryption API). The KMS returns the encrypted data key (Envelop Encryption) or directly returns the ciphertext. The business system initiates a decryption request to the KMS, and after verifying permissions, the KMS returns the decrypted data or data key.

[0114] Traditional symmetric encryption methods are simple and easy to use, but have the following drawbacks: keys need to be securely stored and distributed; once leaked, all encrypted data can be decrypted. Key rotation is difficult, requiring the re-encryption of all historical data, which is costly. Securely distributing keys to various services that need encryption and decryption is a challenge. Access control is weak: any service holding the key can decrypt all data, making fine-grained access control difficult. If the key storage center is compromised, the entire system's security collapses. One-vehicle-one-key encryption is impossible: if the same key is used to encrypt all vehicle data, all vehicle data will be exposed if the key is leaked. However, Key Management Systems (KMS) offer relatively high security, but have the following drawbacks: they require additional hardware (HSM) or software (KMS service) investment, resulting in higher operating costs. Each encryption / decryption may require network calls to KMS, increasing latency and potentially becoming a performance bottleneck. KMS becomes a critical dependency; if it becomes unavailable, the entire system's encryption and decryption functions are paralyzed. A stable network connection is essential, making it unsuitable for offline scenarios. The system architecture is more complex, requiring a dedicated operations and maintenance team to manage KMS.

[0115] This application proposes a cloud-based vehicle data enhanced key derivation encryption and decryption method that combines simple business rules with powerful cryptographic algorithms, providing excellent performance and maintainability while ensuring security. The method's strength lies not only in its advanced technology selection but also in its profound understanding of the characteristics of connected vehicle services. Instead of simply applying cryptographic algorithms, it designs a complete solution tailored to the characteristics of vehicle data, encompassing data collection, key derivation, encrypted storage, and secure access. The core idea of ​​this enhanced key derivation scheme is to transform simple business rules into cryptographically strong secure keys. It goes beyond simple string concatenation, using professional cryptographic algorithms to amplify limited business data into high-quality encryption keys. This is akin to nurturing a seed (limited business data) into a towering tree (powerful encryption key) through a precise cultivation process (key derivation algorithm). This transformation is irreversible; even if an attacker knows the algorithm and input parameters, it is difficult to deduce the original key.

[0116] The embodiments of this application use the AES-GCM encryption algorithm instead of the traditional AES mode because: authentication and encryption are integrated, providing both confidentiality and integrity; a built-in Message Authentication Code (MAC) prevents ciphertext tampering; parallel design, with hardware acceleration supported by modern CPUs, eliminates the need for padding operations compared to CBC mode; and it resists chosen-ciphertext attacks by providing explicit success / failure indicators.

[0117] The methods of the embodiments of this application will be further illustrated below.

[0118] This application proposes a three-layer key derivation system. The system includes a basic material collection layer, a material enhancement and obfuscation layer, and a PBKDF2 key derivation layer. The basic material collection layer does not simply concatenate the last few digits of the VIN with the vehicle model code; instead, it employs a richer basic material collection strategy. The formula is: Basic Material = f(VIN, Vehicle Model Code, Entry Date). The specific collection strategy involves multi-dimensional feature extraction from the VIN, using the last 6 digits as the primary identifier, the middle 3 digits as supplementary features, and the first digit (country of manufacture code) as the regional feature. The vehicle model code is used in its entirety (6 digits). Intelligent parsing of the vehicle entry date not only stores the YYYY-MM-DD format but also extracts information such as the day of the week and quarter, transforming the date into multiple feature dimensions.

[0119] Among them, the aforementioned material enhancement and obfuscation layer enhances the complexity and randomness of the material through multiple technical means, and the feature cross-combination results in enhanced material = VIN feature + date number interleaving insertion + vehicle model code deformation; deterministic salting does not directly use the entry date as salt, but generates a deterministic salt value through SHA-256 hashing. The same input always produces the same salt value, ensuring key consistency; length standardization standardizes variable-length business data into a fixed format to ensure the stability of the derivation process.

[0120] The PBKDF2 key derivation layer described above can use the industry-standard key derivation function: Derived key = PBKDF2(cryptographic material, salt value, iteration count, output length). Algorithm: PBKDF2WithHmacSHA256. Iteration count: Over 100,000 iterations (balancing security and performance). Output length: 256 bits (AES-256 strength). Salt value: 16-byte deterministic salt.

[0121] In this application embodiment, compared with the prior art, it has at least the following beneficial technical effects: In the vehicle-to-everything (V2X) scenario, the number of vehicles may reach millions or even tens of millions, and the data security requirements are high. Although traditional symmetric encryption has good performance, key management is difficult, it cannot achieve one key per vehicle, and the risk of key leakage is high. Although KMS is secure and professional, it is costly, and its network dependence may not be suitable for some offline scenarios in V2X. Therefore, the proposed "enhanced key derivation scheme" is actually a compromise: it does not require key storage, but dynamically derives keys through rules, achieving one key per vehicle while avoiding the key management problems of traditional symmetric encryption, and without the network dependence and cost issues of KMS. However, it also has disadvantages, such as complex algorithm design, and the potential risks if the algorithm is leaked. Depending on specific business needs, if an enterprise has sufficient budget and operational capabilities and has extremely high security requirements, it can choose the KMS scheme. If an enterprise wants to balance security, cost, and performance, and its technical team is capable of designing secure key derivation algorithms, then the enhanced key derivation scheme is an innovative and effective choice.

[0122] Figure 4 This is a flowchart of a cloud-based vehicle data enhancement key derivation encryption method according to an embodiment of this application, such as... Figure 4 As shown, the method may include the following steps.

[0123] Step S402, Data reception and preprocessing.

[0124] In this embodiment, the data verification gateway receives the raw data packets reported by the vehicle network terminal, verifies the data signature and integrity, and extracts the key field, the 17-digit VIN code. For vehicle identification, it queries the vehicle master database to obtain the vehicle model code and the current VIN code, the vehicle's entry date, and establishes a mapping between the vehicle's unique identifier and its business attributes.

[0125] Step S404, Enhance key derivation.

[0126] In this embodiment, the enhanced key derivation process may include VIN smart feature extraction, material enhancement processing, and PBKDF2 derivation execution.

[0127] Optionally, during the VIN intelligent feature extraction process, input VIN="LGWEF2A53JF123456", and output features: last 6 digits: "123456"; country of manufacture code: "L" (China); manufacturer code: "GW"; year code: "F" (2015).

[0128] Optionally, during the material enhancement process, a 256-bit AES key is derived using the last 6 digits of the VIN, the vehicle model code, the entry date, and the global salt value via the PBKDF2 algorithm. For example, the vehicle entry date "2024-03-15" is parsed into multiple dimensions: year: 2024 → "24", month: 03 → "03", "March", "Q1", and day: 15 → "15", "working day". An interleaving algorithm is then used to blend these features, resulting in enhanced material = VIN features + interleaved date insertion + vehicle model code transformation, with a version prefix and suffix added: "VIN_ENC_v1".

[0129] Optionally, during the PBKDF2 derivation process, a 256-bit AES key is derived using the PBKDF2 algorithm. The cryptographic library is invoked to perform key derivation, with the iteration count set to 100,000, outputting the 256-bit AES key material, and ensuring the entire process is executed within a secure memory region.

[0130] The formula is as follows: key=PBKDF2(password,salt=global_salt,iterations=100000,key_length=32).

[0131] Step S406: Encrypt business data.

[0132] In this embodiment, the AES-GCM encryption mode is used to encrypt the complete VIN code with a derived key to obtain the ciphertext and authentication tag.

[0133] The formula is as follows: Ciphertext packet = AES - GCM - Encrypt(

[0134] Key = Derived AES Key Plaintext = complete 17-digit VIN IV = randomly generated 12 bytes) Step S408: Secure data storage.

[0135] In this embodiment, the ciphertext, authentication tag, initialization vector (IV), and key version number used for encryption are stored in a database. The aforementioned vehicle encryption record table may include: vehicle ID (primary key), encrypted VIN (ciphertext + IV), vehicle model code (plaintext), entry date (plaintext), encryption algorithm version, encryption timestamp, and last access time.

[0136] Figure 5 This is a flowchart of a cloud-based vehicle data augmentation key derivation and decryption method according to an embodiment of this application, such as... Figure 5 As shown, the method may include the following steps.

[0137] Step S502, data retrieval and verification.

[0138] In this embodiment, encrypted records are queried based on the vehicle ID to obtain the encrypted VIN, vehicle model code, and entry date, thereby verifying the integrity and freshness of the data.

[0139] Step S504, key re-derived.

[0140] In this embodiment, this is crucial for successful decryption and must be completely identical to the encryption process. All derived parameters are extracted from the encrypted record, ensuring the same algorithm version is used as during encryption, and the integrity and validity of the parameters are verified. Using the exact same feature extraction algorithm, applying the same material enhancement rules, and performing the same number of PBKDF2 iterations, the output is an AES key identical to the one used during encryption. This key exists only in memory and is immediately cleared after use.

[0141] Step S506: Decrypt business data.

[0142] In this embodiment, ciphertext parsing separates the IV and ciphertext data, extracts the authentication tag, and verifies the integrity of the data format.

[0143] Decryption is performed using the following formula: Plaintext VIN=AES-GCM-Decrypt( Key = Re-derived AES key Ciphertext = stored ciphertext data. IV = stored initialization vector.

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

[0145] According to another aspect of the embodiments of this application, and the above... Figure 2 Corresponding to the embodiments of the vehicle data processing method shown, this specification also provides a vehicle data processing apparatus.

[0146] Figure 6 This is a schematic diagram of a vehicle data processing device according to an embodiment of this application, as shown below. Figure 6As shown, the vehicle data processing device 60 may include: a first acquisition module 61, a first extraction module 62, a first generation module 63, and a first encryption module 64. The first acquisition module 61 is used to acquire vehicle identification information and vehicle lifecycle information from the vehicle-to-everything (V2X) terminal data to be stored. The first extraction module 62 is used to extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information, respectively. The multi-dimensional feature information includes at least one target dimension feature information, which differs for different vehicles. The first generation module 63 is used to generate a key for the V2X terminal data using the multi-dimensional feature information. The first encryption module 64 is used to encrypt the V2X terminal data according to the key and to store the encrypted V2X terminal data.

[0147] Figure 7 This is a schematic diagram of another vehicle data processing device according to an embodiment of this application, such as... Figure 7 As shown, the vehicle data processing device 70 may include: a second acquisition module 71, a second extraction module 72, a second generation module 73, a second encryption module 74, and a storage module 75. The second acquisition module 71 is used to acquire vehicle identification information and vehicle lifecycle information from the vehicle network terminal data in response to acquiring vehicle network terminal data to be stored. The second extraction module 72 is used to extract multi-dimensional feature information associated with the vehicle from the identification information and lifecycle information, respectively. The multi-dimensional feature information includes at least one target dimension feature information, which differs for different vehicles. The second generation module 73 is used to generate a key for encrypting the vehicle network terminal data using the multi-dimensional feature information. The second encryption module 74 is used to encrypt the vehicle network terminal data according to the key. The storage module 75 is used to store the encrypted vehicle network terminal data in a database on a cloud server.

[0148] Figure 8 This is a schematic diagram of an electronic device according to an embodiment of this application, such as... Figure 8 As shown, an electronic device 80 is also provided, including: a memory 81 storing an executable program; and a processor 82 for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for processing vehicle data, characterized in that, include: The vehicle's identification information and lifecycle information are obtained from the vehicle-to-everything (V2X) terminal data to be stored in the vehicle. Multi-dimensional feature information associated with the vehicle is extracted from the identification information and the lifecycle information, respectively. The multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles. Using the multi-dimensional feature information, a key is generated for the vehicle network terminal data; The data of the vehicle-to-everything (V2X) terminal is encrypted using the key, and the encrypted V2X terminal data is then stored.

2. The method according to claim 1, characterized in that, The step of generating a key for encrypting the vehicle network terminal data using the multi-dimensional feature information includes: The multi-dimensional feature information is mixed to obtain mixed feature information; The key is generated using the mixed feature information.

3. The method according to claim 2, characterized in that, The multi-dimensional feature information includes vehicle identification features, vehicle type features, and time-series features. The vehicle identification features represent the vehicle's identity, the vehicle type features represent the vehicle's configuration attributes, and the time-series features represent the vehicle's entry time. The process of mixing the multi-dimensional feature information to obtain mixed feature information includes: The temporal features are interleaved and inserted into the vehicle identification features to obtain initial mixed feature information, wherein the initial mixed feature information is obtained by mixing the temporal features and the vehicle identification features; The vehicle type feature is deformed, and the deformed vehicle type feature is inserted into the initial mixed feature information to obtain the mixed feature information.

4. The method according to claim 2, characterized in that, The step of generating the key using the mixed feature information includes: The version prefix and version suffix of the key derivation model are added to the hybrid feature information to obtain the hybrid feature information after addition; Using the key derivation model, a hash value is generated based on the added hybrid feature information and salt value; The key is generated using the hash value.

5. The method according to claim 4, characterized in that, The step of generating a hash value using the key derivation model, based on the added hybrid feature information and salt value, includes: In response to the current iteration being the first iteration, the hash value of the first iteration is generated using the key derivation model based on the added hybrid feature information and the initial salt value in the first iteration. In the generation step, in response to the existence of a previous iteration and a next iteration in the current iteration, the key derivation model is used to determine the hash value of the previous iteration as the salt value of the current iteration in the current iteration, and based on the added mixed feature information and the salt value of the current iteration, the hash value of the current iteration is generated, and the iteration number is incremented by one.

6. The method according to claim 5, characterized in that, The step of generating the key using the hash value includes: The hash value of the current iteration is determined as the salt value for the next iteration, and the next iteration is determined as the current iteration. The generation step is repeated until the number of iterations equals the iteration number threshold. Based on the hash value of the iteration number threshold, the key that satisfies the preset key length is generated.

7. The method according to any one of claims 1 to 6, characterized in that, The step of obtaining the vehicle's identification information from the vehicle network terminal data to be stored includes: The data of the vehicle network terminal to be stored is verified to obtain the verification result; The identification information is extracted from the vehicle network terminal data that the verification results indicate has authenticity and completeness.

8. The method according to claim 7, characterized in that, The verification of the vehicle network terminal data to be stored, and the resulting verification results, include: Using the data signature of the vehicle network terminal data to be stored, the vehicle network terminal data to be stored is verified to obtain a first verification result, wherein the data signature is used to indicate the authenticity of the vehicle from which the vehicle network terminal data originates, and the first verification result is used to indicate whether the vehicle network terminal data to be stored has the authenticity. The hash value contained in the vehicle network terminal data to be stored is compared with the hash value calculated based on the vehicle network terminal data to obtain a comparison result. Based on the comparison result, the vehicle network terminal data to be stored is verified to obtain a second verification result. The second verification result is used to indicate whether the vehicle network terminal to be stored has the integrity.

9. A method for processing vehicle data, characterized in that, The method is applied to a cloud server, and the method includes: In response to acquiring the vehicle-to-everything (V2X) terminal data to be stored, the vehicle's identification information and lifecycle information are obtained from the V2X terminal data. Multi-dimensional feature information associated with the vehicle is extracted from the identification information and the lifecycle information, respectively. The multi-dimensional feature information includes at least one target dimension feature information, and the target dimension feature information is different for different vehicles. Using the multi-dimensional feature information, a key is generated for encrypting the data of the vehicle network terminal; The data of the vehicle network terminal is encrypted according to the key; The encrypted vehicle-to-everything (V2X) terminal data will be stored in the database of the cloud server.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8 or 9.

Images