Intelligent networked vehicle OTA firmware protection and automatic driving model poisoning attack suppression method

Abstract

The invention discloses an intelligent networked vehicle OTA firmware protection and automatic driving model poisoning attack suppression method, and relates to the field of intelligent networked vehicle safety. The method comprises the following steps: S1, developing a vehicle-specification-level protocol fuzz test tool to output a vulnerability report, S2, integrating a vulnerability repair rule based on the vulnerability report, generating a security OTA upgrade package and verification parameters through SM4 encryption and digital signature, and S3, constructing a dynamic feature library based on the upgrade package, inhibiting poisoning attack through dual verification and hierarchical protection, and synchronously generating a compliance log conforming to ISO / SAE 21434. According to the method, the defects of existing OTA firmware security, protocol vulnerability detection and poisoning attack defense are overcome, full-link active defense is realized, security, availability and compliance are considered, and global market access of vehicles is supported.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle security technology, and in particular to a method for protecting over-the-air (OTA) firmware for intelligent connected vehicles and suppressing poisoning attacks on autonomous driving models. Background Technology

[0002] With the rapid development of the intelligent connected vehicle industry, the sales share of new cars equipped with autonomous driving functions has increased significantly. OTA firmware upgrades have become the core means of vehicle function iteration and vulnerability repair. The reliability of autonomous driving models directly determines driving safety. However, intelligent connected vehicles are currently facing severe cybersecurity threats. (1) On the one hand, during the OTA firmware upgrade process, existing technologies mostly use a single encryption algorithm or a simple identity authentication mechanism, which poses the risk that keys are easily stolen and upgrade packages are easily tampered with. Attackers can inject malicious code by tampering with the firmware, causing the vehicle to lose control or malfunction. At the same time, there is a lack of efficient detection methods for potential vulnerabilities in vehicle communication protocols. Traditional fuzzing tools have problems such as low test coverage, high cost, and poor adaptability, making it difficult to find non-strict compliance situations in protocol implementation, leaving opportunities for attackers. (2) On the other hand, autonomous driving models rely on massive amounts of data for training. Attackers can inject a small amount of malicious data to carry out poisoning attacks. Only about 250 malicious samples are needed to implant backdoors in the model. Moreover, poisoning attacks without triggering are difficult to be identified by existing detection methods due to semantic equivalence, leading to incorrect decisions by the model output and causing safety accidents. Existing defense mechanisms are insufficient to suppress such covert attacks and cannot meet security requirements.

[0003] In summary, existing technologies have significant shortcomings in OTA firmware tampering protection, suppression of poisoning attacks on autonomous driving models, and protocol vulnerability detection. They lack an integrated solution that takes into account proactive defense, efficient detection, and adaptation, and there is an urgent need for technical methods that can defend against related threats at the source. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a method for protecting over-the-air (OTA) firmware for intelligent connected vehicles and suppressing poisoning attacks on autonomous driving models. The specific steps are as follows: S1: Collect real vehicle communication data to obtain raw communication logs, parse the raw communication logs for protocol format, and construct a protocol syntax tree; then generate adaptive test cases based on the protocol syntax tree; then perform test execution and vulnerability capture on the adaptive test cases to obtain suspicious test cases; finally, perform vulnerability analysis on the suspicious test cases and generate a vulnerability report.

[0005] Further steps include the following sub-steps: S11: Protocol format parsing and constructing the protocol syntax tree; First, connect the target vehicle's OBD interface using an automotive-grade bus analyzer to collect at least 100 hours of real-vehicle communication data to obtain the raw communication logs. Furthermore, the actual vehicle communication data covers all scenarios including vehicle start-up, idling, acceleration, braking, and sleep.

[0006] Subsequently, a protocol reverse engineering tool was used to perform structured parsing on the original communication logs, extracting the field structure of each protocol, including field length, value range, and verification rules; at the same time, the parsing results were compared field by field with the protocol document provided by the vehicle manufacturer, and extended fields not mentioned in the document were marked; finally, a protocol syntax tree T was constructed based on the parsing results, in which each node corresponds to a field.

[0007] Significant discrepancies exist between the documentation and implementation of in-vehicle protocols. Some in-vehicle protocol fields are not reflected in public documentation due to manufacturer-defined extensions, and general fuzzing tools, which rely on documentation, may miss vulnerabilities in these fields. However, reverse engineering of real vehicle logs can cover actual communication scenarios, solve the problem of mismatch between adaptive test cases and actual protocols, provide an accurate protocol benchmark for the generation of subsequent adaptive test cases, enable testing to cover manufacturer-defined logic, and significantly improve the comprehensiveness of vulnerability discovery.

[0008] S12: Generate adaptive test cases based on the protocol syntax tree; Based on the protocol syntax tree T constructed using S11, the protocol fields that need to be tested are clearly identified. The protocol syntax tree T parses out the complete structure of the vehicle protocol, including the name, data type, and normal value range of each field; then, the risk level of each field is classified: through expert review and functional impact analysis, fields that directly affect driving safety are marked as high risk; status reporting fields are marked as medium risk; and redundant fields are marked as low risk.

[0009] The status reporting fields refer to protocol fields used to transmit vehicle operating status information and not directly involved in driving safety control; the redundant fields refer to protocol fields that have no actual business function and are only used for reserved extensions or format filling.

[0010] The initial population was then generated based on normal field values. High-risk fields were mutated using "boundary mutation" and "random flipping" with a mutation rate of 30%. Medium-risk fields were mutated using "range offset" with a mutation rate of 10%. Low-risk fields were mutated using only "zero-filling" with a mutation rate of 5%. The boundary mutation is a mutation method that generates abnormal values ​​outside the critical value range of the normal value range of the protocol field; the random flip is a mutation method that randomly reverses the binary value of the key control bits in the protocol field.

[0011] Simultaneously, protocol exception test cases are added, including frames with missing check bits, data lengths exceeding protocol specifications, and high-frequency frame attacks; basic validation is performed on the protocol syntax tree T to check whether data types match, lengths match, and field dependencies are reasonable; finally, the valid population is retained as adaptive test cases U_j, which contain both outliers and conform to the basic protocol syntax.

[0012] The adaptive test cases are data packets that conform to the basic protocol format but contain abnormal field values, used to simulate malicious or abnormal data that an attacker may send.

[0013] Vehicle network bandwidth is limited. If all fields are mutated with equal probability, a large number of low-value test cases will be generated, which will consume a lot of testing time but only find a very small number of vulnerabilities. Differential mutation can focus on high-risk fields and significantly improve the discovery rate of critical vulnerabilities in the same amount of time. This avoids invalid testing from consuming vehicle bus resources and can prioritize the discovery of high-risk vulnerabilities that could lead to loss of vehicle control.

[0014] S13: Perform dynamic test execution and vulnerability capture on adaptive test cases to capture suspicious test cases; First, import the adaptive test case U_j generated by S12 into the automotive-grade bus simulator. The bus simulator is connected to the vehicle's gateway ECU via optical fiber to reduce data transmission errors caused by electromagnetic interference. Before testing, the vehicle's actuators were disconnected using a diagnostic tool, leaving only controller communication, and a monitoring agent was deployed on the critical ECU; normal baseline data of the ECU was first obtained by injecting normal communication frames.

[0015] During execution, the bus emulator injects data into U_j at a rate of 100 frames / second, monitors the agent's real-time acquisition of ECU status data, and compares it with the normal baseline data to determine if there are any abnormalities. If any of the following conditions (1), (2), or (3) are met, it is determined to be an abnormal response: (1) A single parameter exceeds the normal threshold; (2) Multiple related parameters show abnormalities simultaneously; (3) High frequency anomalies.

[0016] Furthermore, the status data of the ECU includes the ECU's CPU utilization rate, error codes, communication interruption duration, and the number of ECU restarts.

[0017] When an abnormal response is triggered, the bus emulator immediately pauses the injection, sends a normal communication frame to restore the ECU to its baseline state, and records the ECU model and the adaptive test case that triggered the abnormality as a suspicious test case U_s, providing a basis for subsequent vulnerability analysis.

[0018] Traditional fuzzing tools lack automotive-grade safety controls. The dynamic test execution and vulnerability capture in this step can eliminate physical risks caused by testing. Under the premise of ensuring test security, it can achieve dynamic vulnerability capture and ensure that the discovered vulnerabilities can be reproduced in real communication scenarios.

[0019] S14: Analyze vulnerabilities in suspicious use cases and provide remediation suggestions, generating vulnerability reports; Import no less than 1,000 normal communication frames and suspicious use cases U_s from the same source. Use a byte-by-byte comparison algorithm to locate the difference fields and abnormal values. At the same time, associate with the protocol syntax tree T of S12 to clarify the standard definition of the difference fields and the abnormal deviation dimensions. The so-called normal communication frames are those that come from the same data source and the same communication scenario as the suspicious use case U_s.

[0020] The relevant ECU firmware was then imported into IDA Pro and disassembled with the help of Ghidra. A flowchart of the field processing logic was constructed, the code execution path of the different fields was traced, and the key processing functions were located. If it was found that the code did not contain a value range judgment statement and the buffer had no boundary protection, resulting in abnormal values ​​exceeding the memory allocation range, it was determined to be a "buffer overflow vulnerability". If it was found that the code lacked the validity verification logic of the check bit and the error handling function entered an infinite loop after the abnormal frame was triggered, it was determined to be a "logic vulnerability".

[0021] The system synchronously records the ECU status data when the vulnerability is triggered, and calls the vehicle ECU association topology diagram. Through fault tree analysis, it sorts out the chain reaction that the vulnerability may cause, and combines real vehicle test data to quantitatively evaluate the number of functional modules affected by the vulnerability and the corresponding ISO 26262 standard ASIL level, and clarifies whether the vulnerability involves safety-critical functions; finally, it generates a vulnerability report Vuln. Furthermore, the vulnerability report Vuln includes vulnerability reproduction steps, vulnerability triggering conditions, remediation rules, and a unique vulnerability identifier ID.

[0022] The vulnerability reproduction steps describe how to artificially trigger the vulnerability using technical operation instructions, allowing developers and testers to repeatedly verify whether the vulnerability actually exists. They also provide a traceable verification path for regulatory agencies or third-party audits. The remediation rules specify how to modify firmware or protocol logic to block the vulnerability from a technical perspective. These rules are executable (can be directly converted into code or configuration) and are used to guide developers in writing remediation code, ensuring that the remediation measures precisely match the vulnerability's underlying principles. The remediation rules are precisely designed for different vulnerability types. For example, buffer overflow vulnerabilities require the addition of field value range validation, enabling memory protection mechanisms, and communication recovery procedures after abnormal frame discarding. Logic vulnerabilities require the addition of critical field validation, timeout exit mechanisms for error handling functions, and function degradation strategies.

[0023] S2: Obtain the basic OTA firmware and call the vulnerability report to process the basic OTA firmware to obtain the complete OTA firmware containing vulnerability repair logic; then, perform fragment processing on the complete OTA firmware to obtain fragmented OTA firmware and OTA firmware unique identification information; then, use the SM4 national cryptographic algorithm to encrypt the fragmented OTA firmware and OTA firmware unique identification information; finally, package it to generate a secure OTA firmware upgrade package and transmit it to the vehicle terminal. After the vehicle terminal verifies the security of the secure OTA firmware upgrade package, it completes the installation and vulnerability repair.

[0024] Further steps include the following sub-steps: S21: Call the basic OTA firmware obtained from the vulnerability report processing to obtain the complete OTA firmware containing vulnerability repair logic, and perform fragment processing on the complete OTA firmware to obtain the fragmented OTA firmware and the unique identifier information of the OTA firmware. First, the basic OTA firmware provided by the manufacturer is obtained. Then, the vulnerability report Vuln from S14 is called to parse the "remediation rules" within it. The remediation rules are compiled into executable code modules, and the executable code modules are embedded into the corresponding locations in the basic OTA firmware using a firmware integration tool, forming a complete OTA firmware containing vulnerability remediation logic. Next, the total size of the complete OTA firmware is scanned, the hardware parameters of the vehicle security chip are queried, and the complete OTA firmware is automatically fragmented according to a preset size, resulting in fragmented OTA firmware F_1 to F_n, each fragment being denoted as F_i (i=1,2,...,n). At the same time, unique OTA firmware identification information is generated and denoted as Info.

[0025] Furthermore, the OTA firmware unique identifier information Info includes the version number, the unique identification code VIN code of the adapted vehicle, and the original integrity checksum of the complete OTA firmware calculated by the SHA256 algorithm.

[0026] Intelligent connected vehicle terminals have limited computing resources. Encrypting the entire OTA firmware file would increase encryption time and cause latency, and is prone to interruption due to network fluctuations. Fragmented processing, however, can control the amount of data encrypted per instance within the efficient processing range of the vehicle's security chip. Simultaneously, the checksum in the Info field can be used to verify that the firmware has not been tampered with after subsequent decryption. Fragmenting OTA firmware reduces the amount of data encrypted per instance, adapts to the computing power of the vehicle terminal, and avoids encryption latency caused by excessively large OTA firmware sizes. This improves encryption efficiency to ensure the timeliness of OTA upgrades, while also providing authentication and integrity verification through the unique identifier information of the OTA firmware.

[0027] S22: The SM4 national cryptographic algorithm is used to encrypt the fragmented OTA firmware and the unique identifier information of the OTA firmware; The SM4 encryption engine built into the vehicle security chip is invoked. Using the symmetric key K pre-stored in the secure storage area of ​​the vehicle security chip, SM4 block encryption in CBC mode is performed on each fragment F_i generated in S21. Specifically, for each fragment F_i, the true random number generator TRNG built into the vehicle security chip generates an independent 128-bit random initialization vector IV_i (generated independently for each fragment to avoid affecting all fragments due to leakage of a single vector). Then, with IV_i as the initial value, each fragment F_i is encrypted in 128-bit blocks (each 128-bit block is a group, and padding is added if necessary) to obtain encrypted fragments C_1 to C_n (each encrypted fragment C_i contains IV_i for decryption). At the same time, the same SM4-CBC encryption process is performed on Info to generate an encrypted identifier C_info (containing the corresponding IV_info).

[0028] Furthermore, the symmetric key K is 128 bits, generated by the vehicle manufacturer's key management system through a hardware encryption machine certified by the State Cryptography Administration. Before leaving the factory, it is written into the vehicle's security chip using an encryption burning tool. K is automatically rotated every 90 days through a TLS 1.3 encryption channel, and the rotation process is completed through the encryption channel.

[0029] The SM4 algorithm conforms to national cryptographic standards, and its 128-bit key length can withstand current mainstream brute-force attacks. Furthermore, the encryption speed of the SM4 hardware acceleration module in automotive-grade security chips meets the efficiency requirements of fragmented encryption. The CBC mode design avoids the defect of ECB mode where the same plaintext generates the same ciphertext, thus resisting chosen-plaintext attacks. Balancing encryption security, compliance, and efficiency, it provides a high-strength first layer of protection for OTA firmware content.

[0030] S23: Generate a digital signature; First, all encrypted fragments C_1 to C_n output by S22 are concatenated in order, and then an encrypted identifier C_info is added to form a complete encrypted data string Data. Then, the SM3 hash algorithm is used to calculate Data to generate a 256-bit hash value H. Subsequently, the private key SK stored in the hardware security module in the cloud CA server is called through the encrypted communication interface to digitally sign H and generate a signature value S. At the same time, the public key PK (certified by the national CA institution) corresponding to SK is extracted from the cloud CA server to generate a public key certificate Cert containing the vulnerability unique identifier ID, PK, car manufacturer identity information, certificate validity period, and root CA signature.

[0031] Furthermore, the private key SK is a 2048-bit RSA key, which is never exported from the vehicle security chip and is only used to call the signature function through an internal interface; the signature value S includes the signature algorithm identifier, timestamp, and signature result.

[0032] SM3 is a cryptographic hash algorithm recommended by the State Cryptography Administration. Its collision resistance is superior to SHA-1, preventing attackers from forging identical hash values ​​by modifying data. SM4 encryption alone only ensures the firmware is not stolen, but it cannot verify the firmware's origin. If an attacker obtains the key K illegally, they can forge encrypted malicious firmware and send it to the vehicle. The addition of digital signatures is to achieve identity authentication, ensuring the firmware's legitimate origin and preventing the misrepresentation of encrypted malicious firmware due to encryption without authentication.

[0033] S24: Package and generate a secure OTA firmware upgrade package and transmit it to the vehicle terminal. The vehicle terminal completes the installation and vulnerability patching after the secure OTA firmware upgrade package passes security verification. The encrypted fragments C_1 to C_n of S22, the encrypted identifier C_info, the signature value S of S23, and the public key certificate Cert are packaged into a secure OTA firmware upgrade package P in a fixed format.

[0034] Furthermore, the header of the secure OTA firmware upgrade package P includes the package type (OTA upgrade), total size, number of fragments, and a Unix timestamp T accurate to milliseconds; the middle section contains C_1 to C_n and C_info stored in sequence; and the tail section contains the signature value S, the public key certificate Cert, and the "remediation rules" from the vulnerability report Vuln.

[0035] After encapsulation, the P and decryption verification parameters are transmitted to the vehicle terminal via the TLS 1.3 protocol. The decryption verification parameters are pre-stored in the secure storage area of ​​the vehicle terminal. During the transmission, certificate chain verification and perfect forward confidentiality (PFS) mechanism are enabled. A temporary key is generated for each session, so that even if the long-term key is leaked, the security of historical sessions will not be affected.

[0036] Furthermore, the decryption verification parameters include the index value of the key K in the vehicle security chip (a numerical number used to uniquely identify K in the vehicle security chip) and the hash value of the public key PK; the certificate chain verification refers to the root CA signature pre-stored in the vehicle terminal, which is used to verify the legitimacy of the Cert.

[0037] After receiving P and the decryption verification parameters, the vehicle terminal box's vehicle security chip sends the index value of key K and the ciphertext C_info. Internally, the vehicle security chip locates the symmetric key K through the index, decrypts each C_i to obtain the original fragment F_i, and then concatenates F_1 to F_n in sequence to obtain the complete firmware. The SM4 algorithm is then used to decrypt C_info (the decryption process is completed internally by the vehicle security chip) to obtain the original Info. The SHA256 value of the complete firmware is then recalculated and compared with the checksum in Info. If the two match, it proves that the OTA firmware has not been tampered with during transmission and there is no data corruption, and installation can be performed to finally complete the vulnerability repair and function upgrade. If the two do not match, the firmware is determined to be invalid, installation is refused, and feedback is sent to the cloud to prevent maliciously tampered OTA firmware from being loaded into the vehicle ECU.

[0038] Attackers could intercept legitimate historical upgrade packages and resend them, exploiting the vehicle's trust mechanism for historical packages to cause firmware rollback to a vulnerable older version. Timestamps allow the in-vehicle terminal to refuse to accept packets with expired timestamps. The use of TLS 1.3 further ensures that upgrade packages are not tampered with or stolen during transmission. Through encapsulation specifications and transmission encryption, the integrity and security of upgrade packages from the cloud to the terminal are ensured, resisting replay attacks and transport layer tampering.

[0039] S3: Construct a poisoning data feature library based on a secure OTA firmware upgrade package; then construct a real-time monitoring autonomous driving model and synchronously receive real-time input data from the vehicle, extract features from the real-time input data, compare the extracted features with the constructed poisoning data feature library, and mark suspicious results of the features; then calculate the cumulative risk value based on the suspicious results of the features, and design a protection mechanism based on the cumulative risk value.

[0040] The poisoning data feature library is a core data set that supports the protection against poisoning attacks on autonomous driving models. Further steps include the following sub-steps: S31: Build and update the poisoning data signature database based on secure OTA firmware upgrade packages; Collect historical normal driving data and known poisoning samples, and extract typical features of the poisoning data, including semantic anomaly features, distribution offset features, and temporal inconsistency features; the poisoning data feature library is denoted as Feat, and is regularly updated through secure OTA firmware upgrade packages to cover new poisoning methods.

[0041] First, historical normal multimodal driving data is collected, including traffic light, lane line, and pedestrian images captured by cameras, obstacle point clouds from millimeter-wave radar, and 3D environmental modeling data from lidar; at the same time, known poisoning sample data is collected; then, three core features of the poisoning sample data are extracted: semantic anomaly features, distribution offset features, and protocol violation features.

[0042] Furthermore, for semantic anomaly features, a pre-trained YOLOv8 model is used to perform object detection on the image, and the matching degree between the label and the visual features is calculated; for distribution offset features, the frequency of occurrence of a certain type of obstacle is statistically analyzed and compared with normal data, and if it exceeds a preset offset threshold, it is marked as an offset; for protocol violation features, the judgment is made based on the "repair rules" in the secure OTA firmware upgrade package P.

[0043] The preset offset threshold is a critical standard for judging whether there is poisoning anomaly in the input data of the autonomous driving model. It is derived based on a large amount of real data and technical rules and is used to quantitatively distinguish between normal data characteristics and poisoning data characteristics. When the feature value of real-time data exceeds the critical standard, it is judged as suspicious data.

[0044] The three core features are stored in a structured manner to form a feature library (Feat). Preferably, the default feature weight for protocol violation features is set to 0.4 to prioritize responses to vulnerability-related attacks patched by S2; the default feature weights for the other two types of features are both set to 0.3.

[0045] The feature library (Feat) is stored in a read-only partition of the vehicle security chip and is incrementally updated weekly via a secure OTA firmware upgrade package (P). During the update, the signature of P is verified to ensure the legitimacy of the features.

[0046] Furthermore, when updating the Feature Base (Feat) weekly, the system first needs to verify the signature by calling the public key certificate Cert and the signature value S in the secure OTA firmware upgrade package P. Specifically, S is decrypted using the public key PK in Cert to obtain the hash value H. Then, the SM3 hash value H' is calculated on the new feature data. If H and H' are consistent, it proves that P has not been tampered with, and the new feature data is added to the Feature Base. At the same time, the encrypted identifier C_info in P is decrypted to obtain the firmware version number, ensuring that the Feature Base update matches the current vehicle firmware version and avoiding feature failure due to version mismatch.

[0047] The methods of poisoning attacks on autonomous driving models are constantly evolving. By integrating S24's remediation rules, vulnerability exploitation features at the protocol level can be incorporated into monitoring. A multi-dimensional, dynamically updated feature library can be built, which greatly improves the coverage of poisoning attack detection, especially for attacks that exploit known vulnerabilities.

[0048] S32: Construct a real-time monitoring autonomous driving model and synchronously receive real-time input data from vehicles. Extract features from the real-time input data, compare the extracted features with the constructed poisoning data feature library, and mark suspicious results of the features. A lightweight monitoring module is deployed in the preprocessing stage before inference of the autonomous driving model. The detection module synchronously receives real-time input data D from the vehicle sensors, including real-time image data from cameras, radar point cloud data, and CAN bus control commands.

[0049] First, feature F_D is extracted from D. F_D is a multi-dimensional feature set, specifically including the following three types of features: visual feature vectors extracted from real-time image data from cameras using MobileNetV2, obstacle frequency distribution calculated from radar point cloud data using statistical methods, and specific field values ​​parsed from CAN bus control commands.

[0050] Based on F_D, the type of suspicious feature is determined. Specifically, the cosine similarity between the visual feature vector and the semantic anomaly features in the Feat is calculated. If the obtained cosine similarity is less than the preset similarity threshold, it is marked as semantically suspicious. The frequency distribution of obstacles is compared with the distribution offset features in the Feat. If it exceeds the preset normal frequency threshold, it is marked as distribution suspicious. The specific field values ​​extracted from the CAN bus control command are compared with the protocol violation features in the Feat to mark whether the protocol is suspicious.

[0051] Preferably, the preset similarity threshold is set to 0.7.

[0052] The simplified process of calculating the obstacle frequency distribution using statistical methods is as follows: denoise the original radar point cloud data to remove isolated noise points; use the DBSCAN algorithm to cluster spatially adjacent points into clusters, with each cluster representing an obstacle; identify the type based on the volume and shape of the clusters; set a time window and count the number of occurrences of each type of obstacle within each window; finally, record the correspondence between obstacle type and the number of occurrences per unit time as the frequency distribution.

[0053] This invention simply applies the DBSCAN algorithm without any improvements, therefore the principle of the DBSCAN algorithm will not be elaborated further.

[0054] Secondly, on the one hand, the matching results between F_D and Feat are verified. Each feature in F_D is compared with the corresponding feature standard in Feat to determine whether it triggers a suspected poisoning. On the other hand, the decryption verification parameters output by S24 (the protocol rules corresponding to the public key PK) are called to check whether D conforms to the vulnerability remediation logic integrated in S21. The monitoring module generates a result every 100ms. If D is marked as suspicious by any verification, the timestamp and feature details are recorded.

[0055] Single feature detection is easily circumvented by "semantic equivalence poisoning," where attackers subtly modify the input to make the data appear normal but mislead the model. Dual verification, which combines data features with protocol rules, can identify such hidden attacks, reduce the false negative rate, and ensure that the input data conforms to both the normal distribution and the corrected protocol specifications, thus laying the foundation for the safe operation of the model.

[0056] S33: Calculate the cumulative risk value based on the suspicious results of the marked features, and design protection mechanisms and safeguards based on the calculated cumulative risk value; The monitoring module has a built-in risk counter that calculates the cumulative risk value using the following logic and weights to determine whether to trigger protection: Within a set time window, if the cumulative risk value is greater than or equal to the preset first-level threshold, a first-level protection signal is immediately sent to the vehicle controller. At this time, the monitoring module stores the suspicious data in the vehicle safety log through an encrypted channel. The vehicle safety log is timestamped and HMAC verified to prevent attackers from tampering with it and is used for subsequent tracing. The monitoring module notifies the vehicle controller to suspend the use of the current real-time data and instead call the normal data cache of the previous 10 seconds (the cache is updated by the vehicle controller every 10 seconds to ensure data timeliness), so that the autonomous driving model makes decisions based on reliable data.

[0057] The cumulative risk value is calculated by weighting the semantic anomaly features, distribution offset features, and protocol violation features extracted from the poisoning sample data with preset feature weights and corresponding suspicious feature types.

[0058] If the cumulative risk value is greater than or equal to the preset level 2 threshold within the set continuous time window, it is determined to be a continuous attack and a level 2 protection signal is sent. At this time, the autonomous driving model may have been affected by the poisoning. The vehicle controller immediately stops the current autonomous driving model and activates and loads the backup security model. At the same time, the attack event is immediately reported to the cloud security center through the 5G encrypted channel TLS1.3, along with suspicious data logs, the Feature version number, and the unique vulnerability identifier ID in the secure OTA firmware upgrade package P, so as to facilitate cloud analysis of the attack source.

[0059] Preferably, the preset first-level threshold is set to 0.9, and the preset second-level threshold is set to 2.5; the backup safety model is trained based on an uncontaminated clean dataset, retains only basic driving functions, and the parameters are simplified to 1 / 5 of the original autonomous driving model to ensure fast loading.

[0060] This step's tiered protection balances security and usability, blocking poisoning attacks while avoiding user experience issues caused by over-protection. It also enables immediate action upon detection and repair by forcibly activating the repair module.

[0061] S34: Build a logging system that is compatible with the ISO / SAE 21434 standard; Furthermore, based on the ISO / SAE 21434 standard, a full-link logging system is built. The recorded content includes vulnerability reports (Vuln), information on secure OTA firmware upgrade packages (P), and S3 protection action logs in a structured format. An SM4-encrypted encrypted fragment (with the key bound to the vehicle security chip) is generated every hour and stored in the vehicle's solid-state storage for at least 6 months.

[0062] Furthermore, the information in the secure OTA firmware upgrade package P includes the version number, timestamp, and signature verification result; the protection actions of S3 include the trigger time, suspicious data characteristics, enabled protection level, and backup model switching record.

[0063] Meanwhile, the log recording system automatically generates a compliance report every month to verify the zero-day vulnerability protection cycle: when a new poisoning attack (zero-day vulnerability) not included in the Feat is detected, it is required to prove that a vulnerability report Vuln is generated within 7 days through the automotive-grade protocol fuzzing tool in S1, and then a pushable secure OTA firmware upgrade package P is generated within 14 days through step S2. Finally, protective measures are implemented through step S3, and the process does not exceed 30 days to ensure that the vehicle operates safely for 30 days.

[0064] The compliance report must include an analysis of the correlation between attack characteristics and known vulnerabilities, and be submitted to the regulatory platform via digital signature.

[0065] ISO / SAE 21434 has become the global entry threshold for automotive cybersecurity. Vehicles that do not meet the standard cannot enter mainstream markets such as the EU and China. By linking S1-S3 records, a standard-compliant chain of evidence can be automatically generated, transforming technical protection capabilities into compliance qualifications to support vehicle access to the global market. At the same time, the traceability of logs provides a basis for post-attack analysis.

[0066] The beneficial effects of the present invention on the protection of OTA firmware for intelligent connected vehicles and the suppression of poisoning attacks on autonomous driving models are as follows: (1) The present invention uses a multi-protection system of SM4 national cryptographic algorithm encryption, digital signature and TLS1.3 transmission encryption, combined with a symmetric key periodic rotation mechanism, which can resist brute-force cracking and side-channel attacks, and can verify the legality of firmware source through digital signature, avoid the false reception of encrypted malicious firmware and the alteration or replay of upgrade package during transmission, and ensure the security of the entire OTA firmware from generation to terminal; (2) The present invention avoids the waste of invalid test cases in traditional fuzzing, can accurately discover hidden vulnerabilities that are inconsistent between protocol documents and actual implementation, reduce the complexity and cost of vulnerability detection, and reduce the protocol vulnerability entry points that attackers can exploit; (3) The present invention constructs a dual verification mechanism, integrates vehicle protocol repair rules into the poisoning feature library, which can identify semantic anomalies and intercept poisoning data that exploits protocol vulnerabilities. At the same time, the feature library is dynamically updated to cover new poisoning methods, effectively responding to iterative attacks and ensuring that the autonomous driving model outputs decisions based on trusted data. Attached Figure Description

[0067] Figure 1 This is a schematic diagram illustrating the overall workflow of the intelligent connected vehicle OTA firmware protection and autonomous driving model poisoning attack suppression method of the present invention. Detailed Implementation

[0068] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0069] like Figure 1 As shown, the present invention provides a method for protecting over-the-air (OTA) firmware for intelligent connected vehicles and suppressing poisoning attacks on autonomous driving models, comprising the following steps: S1: Collect real vehicle communication data to obtain raw communication logs, parse the raw communication logs for protocol format, and construct a protocol syntax tree; then generate adaptive test cases based on the protocol syntax tree; then perform test execution and vulnerability capture on the adaptive test cases to obtain suspicious test cases; finally, perform vulnerability analysis on the suspicious test cases and generate a vulnerability report.

[0070] S11: Protocol format parsing and constructing the protocol syntax tree; First, the OBD interface of the target vehicle was connected via a Vector VN1630 automotive-grade bus analyzer, and 120 hours of real-vehicle communication data were continuously collected to obtain the raw communication logs. The real-vehicle communication data covered all scenarios, including vehicle start-up, idling, urban congestion driving, highway cruising, emergency braking, and long-term sleep, and included core vehicle protocol data such as CAN FD, DoIP, and SOME / IP. Each log record included a frame ID, data length, data field, and a millisecond-level timestamp.

[0071] Subsequently, the Kaitai Struct protocol reverse engineering tool was used to perform structured parsing on the original communication logs, extracting the field structure of each protocol, including field length, value range, and verification rules. For the steering control frame of the CAN FD protocol (frame ID=0x18F0050A), the parsed field structure is as follows: Bytes 1-2 are the steering angle, data type uint16, normal value range -500°~+500°, corresponding to hexadecimal 0x0000~0x1770; Byte 3 is the CRC8 check bit, calculated from the first 2 bytes using the polynomial 0x31; Byte 4 is the manufacturer-defined extended field "emergency steering indicator", with a value range of 0x00~0x01, where 0x01 indicates an emergency steering scenario; Bytes 5-8 are reserved bits, with a fixed value of 0x00.

[0072] After comparing the parsing results with the protocol document provided by the vehicle manufacturer field by field, the 4th byte is marked as an extended field. Finally, a protocol syntax tree T is constructed based on the parsing results of all protocols. Each node in T corresponds to a field, specifying the field name, data type, normal value range, inter-field dependencies, and frequency of occurrence.

[0073] This step, by combining reverse analysis of real vehicle logs, covers manufacturer-defined extended fields, solves the vulnerability omission problem caused by the reliance on protocol documents by general fuzzing tools, provides an accurate protocol benchmark for the subsequent generation of adaptive test cases, and significantly improves the comprehensiveness of vulnerability discovery.

[0074] S12: Generate adaptive test cases based on the protocol syntax tree; Based on the protocol syntax tree T built by S11, the protocol fields that need to be tested are identified; the protocol syntax tree T is parsed to reveal the complete structure of the vehicle protocol, including the name, data type, and normal value range of each field; Then, the risk levels of each field are classified: through expert review and functional impact analysis, the steering angle and braking pressure fields are marked as high risk; the vehicle speed and battery charge fields are marked as medium risk; and the reserved field is marked as low risk.

[0075] The following initial population generation and differential mutation operations are then performed: (1) The initial population is generated based on normal field values; First, extract the normal baseline values ​​for each field in the protocol syntax tree T. The normal field values ​​for the turn control frame are: turn angle = 0°, CRC8 checksum, emergency turn flag, and reserved bits. An initial population is generated based on these normal field values, with the initial population size set to 200 entries. All field values ​​in the initial population strictly match the aforementioned normal baseline values ​​to ensure that the initial population fully conforms to the basic protocol syntax specifications and has no abnormal values.

[0076] (2) Variation handling of high-risk fields; Based on expert review and functional impact analysis, steering angle and CRC8 checksum, which directly affect steering control safety, were marked as high-risk fields. A 30% mutation rate was performed on the initial 200 populations, resulting in the mutation of 60 initial populations. Select 30 out of the initial 60 data points to be mutated, and perform boundary mutation on the turning angle field. Specifically, replace the normal 0° with -501° and +501°, both of which exceed the normal boundary of -500° to +500°, to simulate an attacker constructing malicious data with a turning angle that exceeds the range. From the initial population of 60 to be mutated, the remaining 30 entries are selected, and the CRC8 checksum field is randomly flipped. The normal value of the CRC8 checksum 0x3C corresponds to binary 00111100. 1-3 bits are randomly selected and flipped to destroy the validity of the checksum, simulating a checksum tampering attack.

[0077] (3) Variation handling of medium-risk fields; Mark the emergency turn flag as a medium-risk field, perform a mutation operation with a 10% mutation rate, and complete the mutation of the initial 20 populations: Perform a "range offset" mutation on the emergency turning identifier field of the selected 20 initial populations to be mutated. The normal value range is 0x00~0x01. The range offset rule is set to "offset 1 unit beyond the normal range", that is, replace the original 0x00 / 0x01 with 0x02, or offset within the normal range (0x00→0x01, 0x01→0x00), simulating an abnormal value attack of the status field.

[0078] (4) Variation handling of low-risk fields; Mark the reserved bits as low-risk fields, perform a mutation operation with a 5% mutation rate on 200 initial / mutated test cases, and complete the mutation of 10 initial populations: A "zero-filling" mutation is performed on the reserved bit fields of the selected 10 initial populations. The normal value of the reserved bits is 0x00000000. The zero-filling operation specifically involves confirming that all bytes of the reserved bits are 0x00, or refilling some bytes with 0x00, maintaining only the zero-value characteristic, without introducing other abnormal values, and only verifying the impact of abnormal redundant fields on protocol parsing. This completes the generation of the initial population and the differential mutation operation.

[0079] At the same time, protocol exception test cases are added, including frames with missing check bits, frames with data length exceeding the protocol specification, and high-frequency frame attacks; and basic validation is performed on the protocol syntax tree T to check whether the data types match, whether the lengths match, and whether the field dependencies are reasonable. Ultimately, the valid population is retained as the adaptive test case U_j, which includes outliers and conforms to the basic syntax of the protocol.

[0080] After completing the above-mentioned differential mutations, a basic verification of the protocol syntax tree T is performed on all mutated test cases. Finally, valid adaptive test cases are retained, which include abnormal values ​​of different risk levels and meet the basic format requirements of the protocol.

[0081] This step focuses on high-risk fields through differentiated mutations, significantly improving the discovery rate of critical vulnerabilities within the same time frame. It avoids invalid testing consuming vehicle bus resources and prioritizes the discovery of high-risk vulnerabilities that could lead to vehicle loss of control, thus solving the problems of low value and low efficiency of traditional fuzz test cases.

[0082] S13: Perform dynamic test execution and vulnerability capture on adaptive test cases to capture suspicious test cases; First, import the adaptive test case U_j generated by S12 into the Vector VN1630 automotive-grade bus emulator. The bus emulator is connected to the vehicle's gateway ECU via optical fiber to reduce data transmission errors caused by electromagnetic interference.

[0083] Before testing, the vehicle's actuators were disconnected using a diagnostic tool, leaving only controller communication, and a monitoring agent was deployed on the autonomous driving domain controller ADU-200. Normal baseline data of the ECU was obtained by injecting normal communication frames, specifically: CPU utilization was stable at 20%-30%, there were no error codes defined by ISO 14229, communication interruption duration was <10ms, and the number of ECU restarts was 0.

[0084] During execution, the bus emulator injects adaptive test cases U_j at a rate of 100 frames / second, monitors the agent's real-time acquisition of ECU status data, and compares it with the normal baseline data for anomalies. If any of the following conditions are met, it is determined to be an abnormal response: (1) Single parameter exceeds normal threshold: such as CPU utilization > 80%, communication interruption duration > 500ms; (2) Multiple related parameters are abnormal at the same time: such as the simultaneous occurrence of error code 0x13 (incorrect message length or format), CPU utilization soaring to 95%, and communication interruption for 600ms; (3) High frequency anomalies: such as ≥3 abnormal responses within 1 minute.

[0085] When an abnormal response is triggered, the bus emulator immediately pauses the injection, sends a normal communication frame to restore the ECU to its baseline state, and records the ECU model ADU-200 and the adaptive test case that triggered the abnormality as a suspicious test case U_s, providing a basis for subsequent vulnerability analysis.

[0086] This step eliminates physical risks caused by testing through automotive-grade safety controls. While ensuring testing safety, it achieves dynamic vulnerability capture and ensures that discovered vulnerabilities can be reproduced in real communication scenarios, thus solving the deficiency of traditional fuzzing tools that lack automotive-grade safety controls.

[0087] S14: Analyze vulnerabilities in suspicious use cases and provide remediation suggestions, generating vulnerability reports; Import 1500 normal communication frames from the same source and suspicious use cases U_s. Use a byte-by-byte comparison algorithm to locate the difference fields and abnormal values. At the same time, associate with the protocol syntax tree T of S12 to clarify the standard definition of the difference fields and the abnormal deviation dimensions.

[0088] Subsequently, the ADU-200's autonomous driving control firmware was imported into IDA Pro and combined with Ghidra to assist in disassembly, constructing a field processing logic flowchart, tracing the code execution path of the steering angle of the difference field, and locating the key processing function Angle_Process().

[0089] Analysis revealed that the function Angle_Process() did not contain a statement to determine the range of the steering angle, and the steering angle storage buffer was not protected by boundaries. This caused the abnormal value of -501° to be written out of the memory allocation range, which was identified as a "buffer overflow vulnerability". The system synchronously records the ECU status data at the time the vulnerability is triggered: CPU utilization 92%, no error codes, communication interruption 800ms, and 1 restart count. It also calls the vehicle ECU topology diagram and uses fault tree analysis to sort out the chain reaction that the vulnerability may cause (buffer overflow can cause ECU restart, which in turn causes temporary failure of autonomous driving function and causes loss of vehicle cruise control). Combined with real vehicle test data, it quantitatively assesses the number of functional modules affected by the vulnerability and the corresponding ISO 26262 standard ASIL level, and clarifies the safety-critical functions involved in the vulnerability. Finally, it generates a vulnerability report, Vuln.

[0090] The vulnerability report Vuln includes vulnerability reproduction steps, vulnerability triggering conditions, remediation rules, and a unique vulnerability identifier ID. Specifically, the vulnerability reproduction steps are as follows: (1) Establish a communication connection between the Vector VN1630 bus emulator and the ADU-200; (2) Configure the CAN FD bus baud rate to 500kbps; (3) Inject the data field 0x02FE7F0000000000 into the CAN FD frame with frame ID=0x18F0050A; (4) Collect the ECU response. If a communication interruption occurs for ≥500ms and the CPU utilization rate is >80%, the reproduction is considered successful. The specific repair rules are as follows: add steering angle range verification code at the entry point of the Angle_Process() function in the ADU-200 firmware, enable stack overflow protection StackGuard, and send 3 normal synchronization frames to restart communication after discarding abnormal frames. The unique identifier for the vulnerability is "VULN-2025-001".

[0091] S2: Obtain the basic OTA firmware and call the vulnerability report to process the basic OTA firmware to obtain the complete OTA firmware containing vulnerability repair logic; then, perform fragment processing on the complete OTA firmware to obtain fragmented OTA firmware and OTA firmware unique identification information; then, use the SM4 national cryptographic algorithm to encrypt the fragmented OTA firmware and OTA firmware unique identification information; finally, package it to generate a secure OTA firmware upgrade package and transmit it to the vehicle terminal. After the vehicle terminal verifies the security of the secure OTA firmware upgrade package, it completes the installation and vulnerability repair.

[0092] S21: Call the basic OTA firmware obtained from the vulnerability report processing to obtain the complete OTA firmware containing vulnerability repair logic, and perform fragment processing on the complete OTA firmware to obtain the fragmented OTA firmware and the unique identifier information of the OTA firmware. First, the basic OTA firmware provided by the manufacturer is obtained. Then, the vulnerability report Vuln of S14 is called to parse the "remediation rules" and compile them into a C language executable code module. Using the Vector DaVinci Configurator firmware integration tool, the executable code module is embedded into the entry point of the Angle_Process() function of the basic OTA firmware's steering control module, forming a complete OTA firmware containing vulnerability remediation logic.

[0093] Next, the total size of the complete OTA firmware is scanned, the hardware parameters of the Infineon AURIX TC397 automotive security chip are queried, and the complete OTA firmware is automatically fragmented into 1MB preset sizes to obtain fragmented OTA firmware F_1 to F_800, each fragment is denoted as F_i (i=1,2,...,800); at the same time, unique OTA firmware identification information is generated and denoted as Info.

[0094] The unique identifier information Info of the OTA firmware includes the version number, the unique identification code VIN code of the adapted vehicle, and the original integrity checksum of the complete OTA firmware calculated by the SHA256 algorithm.

[0095] This step controls the amount of encrypted data per transaction within the efficient processing range of the vehicle security chip by using fragmented processing, avoiding the encryption delay and network interruption risks caused by whole-packet encryption. At the same time, the checksum in the Info provides a basis for subsequent firmware integrity verification, solving the problems of low efficiency and poor security of OTA upgrades caused by limited computing resources of vehicle terminals.

[0096] S22: The SM4 national cryptographic algorithm is used to encrypt the fragmented OTA firmware and the unique identifier information of the OTA firmware; The SM4 encryption engine built into the Infineon AURIX TC397 automotive security chip is invoked. Using the symmetric key K pre-stored in the secure storage area of ​​the automotive security chip, SM4 block encryption in CBC mode is performed on each fragment F_i generated in S21. Specifically, for each fragment F_i, the true random number generator TRNG built into the automotive security chip generates an independent 128-bit random initialization vector IV_i. Taking fragment F_1 as an example, IV_1 = 0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d is generated. Then, using IV_1 as the initial value, F_1 ​​is encrypted in 128-bit blocks (each group consists of 128 bits, with 0x00 padded at the end if less than 128 bits), resulting in encrypted fragment C_1 (the first 16 bytes are IV_1, and the rest is encrypted data). Similarly, the encryption of F_2 to F_800 is completed, resulting in encrypted fragments C_2 to C_800.

[0097] At the same time, the same SM4-CBC encryption process is performed on Info to generate the encrypted identifier C_info.

[0098] The symmetric key K is 128 bits, with a specific key value of 0x0123456789ABCDEF0123456789ABCDEF. It is generated by the vehicle manufacturer's key management system through a hardware encryption machine certified by the State Cryptography Administration. Before leaving the factory, it is written into the vehicle's security chip using an encryption burning tool. K is automatically rotated every 90 days through a TLS 1.3 encryption channel, and the rotation process is completed through the encryption channel.

[0099] The SM4 algorithm conforms to the national cryptographic standard, and its 128-bit key length can resist current mainstream brute-force attacks. The SM4 hardware acceleration module of automotive-grade in-vehicle security chips has an encryption speed of 1GB / s, which meets the efficiency requirements of fragmented encryption. The CBC mode design avoids the defect of the same plaintext generating the same ciphertext in the ECB mode, and can effectively resist chosen plaintext attacks, providing the first layer of high-strength protection for OTA firmware content and solving the problem of insufficient security of a single encryption algorithm.

[0100] S23: Generate a digital signature; First, concatenate all encrypted fragments C_1 to C_800 output by S22 in order, and then add the encryption identifier C_info to form a complete encrypted data string Data; then use the SM3 hash algorithm to calculate Data to generate a 256-bit hash value. Subsequently, through the PKCS11 standard encrypted communication interface, the private key SK stored in the Hardware Security Module (HSM) on the cloud CA server is invoked to digitally sign H, generating a signature value S. The private key SK is a 2048-bit RSA key, which is never exported from the vehicle security chip and is only used to call the signing function through an internal interface. At the same time, the public key PK (certified by the national CA institution) corresponding to SK is extracted from the cloud CA server, and a public key certificate Cert containing the vulnerability's unique identifier ID, PK, car company identity information, certificate validity period, and root CA signature is generated.

[0101] SM3 is a cryptographic hash algorithm recommended by the State Cryptography Administration. Its collision resistance is better than SHA-1, which can prevent attackers from forging the same hash value after modifying the data. The addition of digital signature realizes the identity authentication of the firmware source, avoids the problem of encrypted malicious firmware being mistakenly received due to encryption without authentication, and solves the security risks of untrusted firmware source in existing OTA upgrades.

[0102] S24: Package and generate a secure OTA firmware upgrade package and transmit it to the vehicle terminal. The vehicle terminal completes the installation and vulnerability patching after the secure OTA firmware upgrade package passes security verification. The encrypted fragments C_1 to C_800 of S22, the encrypted identifier C_info, the signature value S of S23, and the public key certificate Cert are packaged into a secure OTA firmware upgrade package P in a fixed format.

[0103] After encapsulation, the P and decryption verification parameters are transmitted to the vehicle terminal via the TLS 1.3 protocol. The decryption verification parameters are pre-stored in the secure storage area of ​​the vehicle terminal. During the transmission, certificate chain verification and perfect forward confidentiality (PFS) mechanism are enabled. A temporary key is generated for each session, so that even if the long-term key is leaked, the security of historical sessions will not be affected.

[0104] The decryption verification parameters include the index value of key K and the hash value of public key PK in the vehicle security chip; the certificate chain verification refers to the root CA signature pre-stored in the vehicle terminal, which is used to verify the legitimacy of Cert.

[0105] After receiving P and the decryption verification parameters, the vehicle terminal sends the index value 0x000A of the key K and the ciphertext C_info to the vehicle security chip. The vehicle security chip internally locates the symmetric key K through the index, decrypts each C_i to obtain the original fragment F_i, and then concatenates F_1 to F_800 in sequence to obtain the complete firmware. The SM4 algorithm is then used to decrypt C_info (the decryption process is completed internally by the vehicle security chip) to obtain the original Info. The SHA256 value of the complete firmware is then recalculated and compared with the checksum in Info. If the two match, it proves that the OTA firmware has not been tampered with during transmission and there is no data corruption, and installation can be performed to finally complete the vulnerability repair and function upgrade. If the two do not match, the firmware is determined to be invalid, installation is refused, and feedback is sent to the cloud to prevent maliciously tampered OTA firmware from being loaded into the vehicle ECU.

[0106] This step employs multiple layers of protection, including TLS 1.3 transmission encryption, digital signature verification, and integrity verification, to resist replay attacks and transport layer tampering, thus resolving the issues of upgrade packages being easily tampered with and keys being easily stolen during OTA upgrades. The timestamp design also avoids the risk of firmware rollback caused by the repeated sending of historically legitimate upgrade packages.

[0107] S3: Construct a poisoning data feature library based on a secure OTA firmware upgrade package; then construct a real-time monitoring autonomous driving model and synchronously receive real-time input data from the vehicle, extract features from the real-time input data, compare the extracted features with the constructed poisoning data feature library, and mark suspicious results of the features; then calculate the cumulative risk value based on the suspicious results of the features, and design a protection mechanism based on the cumulative risk value.

[0108] S31: Build and update the poisoning data signature database based on secure OTA firmware upgrade packages; Collect 1 million kilometers of historical normal driving data and known poisoning samples, and extract typical features of the poisoning data, including semantic anomaly features, distribution offset features, and temporal inconsistency features; the poisoning data feature library is denoted as Feat, and is regularly updated through secure OTA firmware upgrade packages to cover new poisoning methods.

[0109] First, historical normal multimodal driving data was collected, including images of traffic lights, lane lines, and pedestrians captured by cameras, obstacle point clouds from millimeter-wave radar (128 points per frame, detection distance 0-200m), and environmental 3D modeling data from lidar (point density 200 points / ㎡). At the same time, the following known poisoning sample data were collected: "red light to green light" images tampered with by generative AI, fake "pedestrian point clouds in areas without actual obstacles", and "turning angle +500° at a vehicle speed of 120km / h" data with contradictory time sequences; Next, three core features of the poisoning sample data were extracted: semantic anomaly features, distribution offset features, and protocol violation features.

[0110] For semantic anomaly features, a pre-trained YOLOv8 model is used to perform object detection on the image, and the cosine similarity algorithm is used to calculate the matching degree between the sample visual feature vector and the standard visual feature vector corresponding to the label. For distribution offset features, the frequency of occurrence of a certain type of obstacle is statistically analyzed and compared with normal data. If it exceeds the preset offset threshold, it is marked as an offset. For protocol violation features, the judgment is based on the "repair rules" in the secure OTA firmware upgrade package P. For example, the steering angle must be within the range of -500° to +500°. If it exceeds this range, it is considered a violation.

[0111] The preset offset threshold is a critical standard for judging whether there is poisoning anomaly in the input data of the autonomous driving model. It is derived based on a large amount of real data and technical rules and is used to quantitatively distinguish between normal data characteristics and poisoning data characteristics.

[0112] Semantic anomaly features, distribution offset features, and protocol violation features are stored in a structured format of "feature type-specific feature-specific rule-weight" as a poisoning data feature library (Feat). The Fat uses SON Lines format and is stored in a read-only partition of the Infineon AURIX TC397 automotive security chip. The protocol violation feature has a weight of 0.4 to prioritize responses to attacks related to vulnerabilities patched by S2; the other two feature types have a weight of 0.3. A specific storage example is shown below. Feature type: semantic anomaly feature; specific feature: traffic light label-visual feature matching degree; specific rule: if the cosine matching degree between the standard feature corresponding to the traffic light image label and the sample feature is <0.95, it is judged as semantic anomaly; weight: 0.3; Feature type: Protocol violation feature; Specific feature: Steering angle value range; Specific rule: If the steering angle field value exceeds the range of -500° to +500°, it is judged as a protocol violation; Weight: 0.4.

[0113] The feature library (Feat) is stored in a read-only partition of the Infineon AURIX TC397 automotive security chip. It is incrementally updated weekly via a secure OTA firmware upgrade package (P) (only new features are added, and old features are not deleted), and the signature of P is verified during the update to ensure the legitimacy of the features.

[0114] When updating the Feature Base (Feat) weekly, the system first calls the public key certificate Cert and signature value S from the secure OTA firmware upgrade package P. It then uses the public key PK in Cert to decrypt S, obtaining the hash value H. Next, it calculates the SM3 hash value H' for the new feature data. If H and H' match, it proves that P has not been tampered with, and the new feature data is added to the Feature Base. At the same time, it decrypts the encrypted identifier C_info in P to obtain the firmware version number, ensuring that the Feature Base update matches the current vehicle firmware version and avoiding feature failure due to version mismatch.

[0115] This step integrates the remediation rules in secure OTA firmware upgrade packages, incorporates protocol-level vulnerability exploitation features into monitoring, and constructs a multi-dimensional, dynamically updated poisoning data feature library. This solves the problem of incomplete feature library coverage and inability to cope with new types of attacks in existing poisoning attack defenses.

[0116] S32: Construct a real-time monitoring autonomous driving model and synchronously receive real-time input data from vehicles. Extract features from the real-time input data, compare the extracted features with the constructed poisoning data feature library, and mark suspicious results of the features. A lightweight monitoring module is deployed in the preprocessing stage before inference of the autonomous driving model. The detection module synchronously receives real-time input data D from the vehicle sensors, including real-time image data from cameras, radar point cloud data, and CAN bus control commands.

[0117] First, feature F_D is extracted from D. F_D is a multi-dimensional feature set, specifically including the following three types of features: visual feature vectors extracted from real-time image data from cameras using MobileNetV2, obstacle frequency distribution calculated from radar point cloud data using statistical methods, and specific field values ​​parsed from CAN bus control commands.

[0118] Based on F_D, the type of suspicious feature is determined. Specifically, the cosine similarity between the visual feature vector and the semantic anomaly features in the Feature is calculated. If the obtained cosine similarity is <0.7, it is marked as semantically suspicious. The frequency distribution of obstacles is compared with the distribution offset features in the Feature. If it exceeds the preset normal frequency threshold, it is marked as distribution suspicious. The specific field values ​​extracted from the CAN bus control command are compared with the protocol violation features in the Feature to mark whether the protocol is suspicious.

[0119] The preset normal frequency threshold is calibrated based on normal data, such as the normal occurrence frequency of vehicles in high-speed scenarios being ≤15 times / minute.

[0120] The simplified process of calculating the obstacle frequency distribution using statistical methods is as follows: The original radar point cloud is denoised to remove isolated noise points (using voxel filtering, voxel size 0.5m×0.5m×0.5m); spatially adjacent points are clustered into clusters using the DBSCAN algorithm (eps=1.5m, min_samples=5), with each cluster representing an obstacle; the type is identified based on the volume and shape of the clusters; a 30-second time window is set, and the occurrence frequency of each type of obstacle is counted within each window; finally, the correspondence between obstacle type and the number of occurrences per unit time is recorded as the frequency distribution.

[0121] This invention simply applies the DBSCAN algorithm without any improvements, therefore the principle of the DBSCAN algorithm will not be elaborated further.

[0122] Secondly, on the one hand, the matching result between F_D and Feat is verified. Each feature in F_D is compared with the corresponding feature standard in Feat to determine whether poisoning is suspected. On the other hand, the decryption verification parameters (the protocol rules corresponding to the public key PK) output by S24 are called to check whether D conforms to the vulnerability repair logic integrated in S21.

[0123] The monitoring module generates a result every 100ms. If D is marked as suspicious by any check, the timestamp and feature details are recorded.

[0124] This double verification step effectively identifies hidden attacks such as semantically equivalent poisoning, solves the problem of high false negative rate in existing single-feature detection, and ensures that the input data conforms to both normal distribution and the repaired protocol specifications.

[0125] S33: Calculate the cumulative risk value based on the suspicious results of the marked features, and design protection mechanisms and safeguards based on the calculated cumulative risk value; The monitoring module has a built-in risk counter that calculates the cumulative risk value using the following logic and weights to determine whether to trigger protection: If the cumulative risk value is ≥0.9 within a set time window of 1 minute, a first-level protection signal is immediately sent to the vehicle controller. At this time, the monitoring module stores the suspicious data in the vehicle security log through an encrypted channel (AES-256 encryption). The vehicle security log is timestamped and HMAC verified (the key is bound to the vehicle security chip) to prevent attackers from tampering with it and is used for subsequent tracing. The monitoring module instructs the vehicle controller to suspend the use of the current real-time data and instead call the cached normal data from the previous 10 seconds (the cache is updated by the vehicle controller every 10 seconds to ensure data timeliness), enabling the autonomous driving model to make decisions based on reliable data.

[0126] The cumulative risk value is calculated by weighting the semantic anomaly features, distribution offset features, and protocol violation features extracted from the poisoning sample data with the corresponding suspicious feature types. Assuming that one protocol suspicion and two semantic suspicions are detected within one minute, the cumulative risk value within one minute is calculated as 0.4×1+0.3×2=1.0 based on the weight of the protocol violation feature (0.4) and the weight of the semantic anomaly feature (0.3).

[0127] If the cumulative risk value is ≥2.5 within a set continuous time window of 10 minutes, it is judged as a continuous attack and a level 2 protection signal is sent. At this time, the autonomous driving model may have been affected by the poisoning. The vehicle controller immediately stops the current autonomous driving model and activates and loads the backup security model. At the same time, the attack event is immediately reported to the cloud security center through the 5G encrypted channel TLS1.3, along with suspicious data logs, the Feature version number, and the unique vulnerability identifier ID in the secure OTA firmware upgrade package P, so as to facilitate cloud analysis of the attack source.

[0128] The backup safety model is trained on a 100,000 km uncontaminated, unpoisoned real driving dataset. It retains only basic driving functions such as driving straight, braking, and following distance ≥50m, and the parameters are simplified to 1 / 5 of the original autonomous driving model to ensure rapid loading.

[0129] This step balances security and availability through a tiered protection mechanism, blocking poisoning attacks while avoiding user experience issues caused by over-protection, thus solving the problem of existing defense mechanisms that struggle to balance security and availability.

[0130] S34: Build a logging system that is compatible with the ISO / SAE 21434 standard; Based on the ISO / SAE 21434 standard, a full-chain logging system was built, recording information including vulnerability reports (Vuln), information on secure OTA firmware upgrade packages (P), and S3 protection actions. The logs use a structured JSON Lines format, generating an SM4-encrypted encrypted fragment every hour (the key is bound to the vehicle's security chip), stored on a 128GB vehicle solid-state drive, and retained for at least 6 months.

[0131] Meanwhile, the logging system automatically generates a compliance report monthly to verify the zero-day vulnerability protection cycle: when a new poisoning attack not included in the Feat is detected, it must be proven that a vulnerability report Vuln is generated within 7 days using the automotive-grade protocol fuzzing tool in S1, then a pushable, secure OTA firmware upgrade package P is generated within 14 days through step S2, and finally, protective measures are implemented through step S3, within no more than 30 days, ensuring the vehicle operates safely for 30 days. The compliance report must include a correlation analysis between attack characteristics and known vulnerabilities and be submitted to the regulatory platform via digital signature.

[0132] This step, through end-to-end logging and compliance report generation, meets the requirements of the ISO / SAE 21434 standard and solves the problem that existing technologies lack compliance support and cannot meet global market access requirements.

[0133] This embodiment successfully discovered and repaired the vehicle protocol buffer overflow vulnerability by fully executing the technical steps S1-S3, generating a secure OTA firmware upgrade package, achieving precise protection against poisoning attacks, and meeting international network security compliance standards.

[0134] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for intelligent networked vehicle OTA firmware protection and automatic driving model poisoning attack suppression, characterized in that, Comprise the following steps: S1: Collecting real vehicle communication data to obtain original communication log, and performing protocol format analysis on the original communication log to construct a protocol syntax tree; then generating adaptive test cases according to the protocol syntax tree; then performing test execution and vulnerability capture on the adaptive test cases to obtain suspicious cases; finally, performing vulnerability analysis on the suspicious cases to generate a vulnerability report; The real vehicle communication data covers the whole scene of vehicle starting, idling, accelerating, braking and hibernation; The adaptive test case is a data packet that conforms to the basic format of the protocol but contains abnormal field values, which is used to simulate malicious or abnormal data that an attacker may send; S2: Obtain the basic OTA firmware, and call the vulnerability report to process the basic OTA firmware to obtain a complete OTA firmware containing vulnerability repair logic; then perform fragmentation processing on the complete OTA firmware to obtain fragmented OTA firmware and OTA firmware unique identification information; Then, the SM4 national encryption algorithm is used to encrypt the fragmented OTA firmware and the OTA firmware unique identification information; finally, a secure OTA firmware upgrade package is generated and transmitted to the vehicle terminal, and the vehicle terminal completes the installation and vulnerability repair after passing the security verification of the secure OTA firmware upgrade package; S3: Construct a poisoning data feature library based on the secure OTA firmware upgrade package; then construct a real-time monitoring automatic driving model and synchronously receive real-time input data of the vehicle, extract features from the real-time input data, and compare the extracted features with the constructed poisoning data feature library to mark the suspicious results of the features; Then, calculate the cumulative risk value based on the suspicious results of the features, and design a protection mechanism based on the cumulative risk value; The poisoning data feature library is a core data set supporting the protection of automatic driving model poisoning attacks; The real-time input data includes real-time image data of the camera, radar point cloud data, and CAN bus control instructions.

2. The intelligent networked vehicle OTA firmware protection and automatic driving model poisoning attack suppression method of claim 1, wherein Step S1 includes the following sub-steps: S11: Protocol format analysis, constructing a protocol syntax tree; Connect the OBD interface of the target vehicle through a vehicle-level bus analyzer to collect real vehicle communication data and obtain original communication log; and use a protocol reverse tool to perform structured analysis on the original communication log, and construct a protocol syntax tree based on the analysis result; S12: Generating adaptive test cases according to the protocol syntax tree; Divide each field in the protocol syntax tree into risk levels, and generate adaptive test cases according to the initial population generation and differential mutation operation of each field; S13: Dynamically test the execution and vulnerability capture of the adaptive test cases to capture suspicious cases; Import the adaptive test cases into a vehicle-level bus simulator, and deploy a monitoring agent on an electronic control unit (ECU) to collect real-time state data of the ECU; if any of the following conditions (1), (2), and (3) is met, it is determined to be an abnormal response: (1) Single parameter exceeds normal threshold; (2) Multiple associated parameters appear abnormal at the same time; (3) High frequency abnormality; When an abnormal response is triggered, the bus simulator immediately suspends injection, sends a normal communication frame to restore the baseline state of the ECU, and records the adaptive test case that triggered the abnormality as a suspicious case; S14: Vulnerability analysis and repair suggestion are performed on the suspicious use case, and a vulnerability report is generated; The suspicious use case is traced back, and the vulnerability type is determined to be "buffer overflow vulnerability" or "logic vulnerability". The impact of the vulnerability is quantitatively evaluated in combination with real vehicle test data, and finally a vulnerability report is generated.

3. The intelligent network connection car OTA firmware protection and automatic driving model poisoning attack suppression method according to claim 1 or 2, characterized in that, The vulnerability report includes vulnerability reproduction steps, trigger conditions, repair rules, and a unique vulnerability identification ID; The vulnerability reproduction steps refer to technical operation instructions describing how to artificially trigger the vulnerability, which are used by developers and testers to repeatedly verify whether the vulnerability actually exists, and also provide a traceable verification path for regulatory agencies or third-party audits. The repair rules refer to clear instructions on how to modify the firmware or protocol logic to block the vulnerability from a technical perspective, which are executable and used to guide developers in writing repair code. Repair rules are designed accurately for different vulnerability types. Buffer overflow vulnerabilities require adding field value range checking, enabling memory protection mechanisms, and communication recovery processes after exception frame discarding. Logic vulnerabilities require supplementing key field checking, adding a timeout exit mechanism to error handling functions, and a function degradation strategy.

4. The intelligent network connection car OTA firmware protection and automatic driving model poisoning attack suppression method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S21: Call the obtained basic OTA firmware in the vulnerability report processing to obtain a complete OTA firmware containing vulnerability repair logic, and perform fragmentation processing on the complete OTA firmware to obtain fragmented OTA firmware and OTA firmware unique identification information; Obtain the basic OTA firmware provided by the manufacturer, parse the "repair rules" in the vulnerability report, and compile them into executable code modules embedded in the basic OTA firmware to form a complete OTA firmware; Fragment the complete OTA firmware and generate OTA firmware unique identification information; S22: Encrypt the fragmented OTA firmware and OTA firmware unique identification information using the SM4 national encryption algorithm; Perform SM4 block encryption in CBC mode on each fragmented OTA firmware and OTA firmware unique identification information to obtain encrypted fragments and encrypted identification; S23: Generate a digital signature; Concatenate all encrypted fragments in order and append the encrypted identification to form a complete encrypted data string. Then calculate a 256-bit hash value from the encrypted data string, and then digitally sign the hash value. Specifically, the hash value is digitally signed by calling the private key stored in the hardware security module in the cloud CA server through the encrypted communication interface, to generate a signature value. At the same time, extract the public key certified by the national CA agency corresponding to the private key from the cloud CA server to generate a public key certificate; S24: Package the secure OTA firmware upgrade package and transmit it to the vehicle terminal. The vehicle terminal completes installation and vulnerability repair after passing the security verification of the secure OTA firmware upgrade package; Package the encrypted fragments, encrypted identification, signature value, and public key certificate into an upgrade package; After packaging is complete, transmit the upgrade package to the vehicle terminal through the TLS1.3 protocol; After receiving the upgrade package, the vehicle terminal decrypts each encrypted fragment to obtain the original fragments, concatenates all original fragments in order to obtain the complete OTA firmware, and finally completes vulnerability repair and function upgrade.

5. The intelligent network connection car OTA firmware protection and automatic driving model poisoning attack suppression method according to claim 1 or 4, characterized in that, The OTA firmware unique identification information includes a version number, a unique identification code of the vehicle, and a complete OTA firmware original integrity check value calculated by a SHA256 algorithm.

6. The intelligent network connection car OTA firmware protection and automatic driving model poisoning attack suppression method according to claim 4, characterized in that, The process of performing the SM4 block encryption in the CBC mode is: calling an SM4 encryption engine built in the on-board security chip, using a symmetric key K pre-stored in a secure storage area of the on-board security chip to encrypt each fragment and the OTA firmware unique identification information; the symmetric key K is 128 bits, is generated by a hardware encryption machine authenticated by the National Cryptography Administration, and is automatically replaced once every 90 days through a TLS1.3 encryption channel, and the replacement process is completed through the encryption channel.

7. The intelligent network connection car OTA firmware protection and automatic driving model poisoning attack suppression method according to claim 1, characterized in that, Step S3 includes the following sub-steps: S31: constructing and updating the poisoning data feature library according to the secure OTA firmware upgrade package; Collecting historical normal driving data, known poisoning sample data and a secure OTA firmware upgrade package P to construct a poisoning data feature library, and incrementally updating the poisoning data feature library every week through the secure OTA firmware upgrade package and verifying the signature when updating to ensure the legality of the features; S32: constructing a real-time monitoring automatic driving model and synchronously receiving real-time input data of the vehicle, extracting features from the real-time input data, comparing the extracted features with the constructed poisoning data feature library, and marking suspicious results of the features; The automatic driving model receives real-time input data of the on-board sensor in real time, compares the input data with the poisoning data feature library to determine whether the input data is suspicious, and determines the suspicious feature type; S33: calculating a cumulative risk value according to the marked suspicious results of the features, and designing a protection mechanism and a protection measure based on the calculated cumulative risk value; Designing a two-level protection mechanism, if the cumulative risk value reaches a preset first threshold or a preset second threshold within a set time window, the automatic driving model triggers a protection of a corresponding level and executes a protection measure; The cumulative risk value is calculated by weighted summation according to preset feature weights of semantic anomaly features, distribution offset features and protocol violation features extracted from the poisoning sample data and corresponding suspicious feature types; S34: building a log recording system adapted to the ISO / SAE 21434 standard; Recording the processing process and results of the protection mechanism to form a compliance log recording report; The log recording system automatically generates a compliance report every month, when a new poisoning attack not included in the poisoning data feature library is detected, a vulnerability report generated by the automotive-grade protocol fuzzing test tool in step S1 within 7 days is required, then a pushable secure OTA firmware upgrade package is generated through step S2 within 14 days, and finally the protection measure is executed through step S3, and the time is not more than 30 days. 8.The method of claim 7, wherein, In step S31, when performing incremental update through the secure OTA firmware upgrade package every week, the public key certificate and the signature value in the secure OTA firmware upgrade package are first called to perform signature verification. Specifically, the public key in the public key certificate is used to decrypt the signature value to obtain a hash value H, and then an SM3 hash value H' is calculated for the new feature data. If H and H' are consistent, it is proved that the secure OTA firmware upgrade package has not been tampered with, and the new feature is added to the poisoning data feature library. At the same time, the encrypted identifier in the secure OTA firmware upgrade package is decrypted to obtain the firmware version number therein, so as to avoid version misplacement leading to invalidation of the new feature. 9.The intelligent vehicle OTA firmware protection and automatic driving model poisoning attack suppression method of claim 7, wherein, In step S33, the protection mechanism and protection measures are specifically as follows: In a set unit time window, if the calculated cumulative risk value is greater than or equal to a preset first threshold value, the suspicious data is stored in the vehicle-mounted safety log through an encrypted channel, and the vehicle control unit suspends the use of the current real-time data, and instead calls the normal data cache of the previous 10 seconds and the cache area is updated every 10 seconds; In a set continuous time window, if the calculated cumulative risk value is greater than or equal to a preset second threshold value, the vehicle control unit immediately stops the current automatic driving model and activates the loading of the backup safety model; at the same time, the attack event is immediately reported to the cloud security center through a 5G encrypted channel.

Images