Vehicle-mounted CAN communication security verification method, system and device and storage medium
By parsing DBC files and building attack test cases, the system automatically injects malicious messages and generates structured reports, solving the problem of low efficiency in vehicle CAN communication security verification and achieving efficient SecOC security mechanism verification and compliance evidence generation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-04
- Publication Date
- 2026-04-10
AI Technical Summary
In existing technologies, the security verification of in-vehicle CAN communication is inefficient, relying on manual testing or semi-automated scripts, resulting in incomplete test coverage and difficulty in generating compliance evidence, which cannot meet the high-efficiency requirements of automotive cybersecurity certification.
By parsing DBC files to extract target CAN messages and SecOC configuration information, attack test cases are constructed, malicious messages are injected into the CAN bus, ECU response information is collected in real time, and structured test reports are generated based on regulatory standards to achieve automated verification.
It has implemented automated testing of the SecOC security mechanism, supports confidentiality and integrity verification, automatically generates compliance evidence, and improves the efficiency of automotive cybersecurity certification.
Smart Images
Figure CN121841840A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication security testing technology, and in particular to a method, system, device and storage medium for verifying vehicle-mounted CAN communication security. Background Technology
[0002] With the development of intelligent and connected vehicles, in-vehicle networks (especially CAN bus) face security threats such as replay attacks, message tampering, and information theft. To address these risks, international and domestic regulations have been introduced: According to GB 44495–2024 and UNR155 regulations, communication between key vehicle ECUs must be able to prevent eavesdropping, tampering, and replay attacks.
[0003] The industry generally adopts the AUTOSAR SecOC (Secure Onboard Communication) protocol to achieve the above security requirements. However, at present, in the research and development and certification stages, the verification of the deployment effect of SecOC still relies on manual testing or semi-automated scripts, resulting in incomplete test coverage, difficulty in generating compliance evidence, and fragmented toolchains, thus leading to low efficiency in automotive cybersecurity certification.
[0004] Therefore, improving the efficiency of automotive cybersecurity certification has become an urgent problem to be solved.
[0005] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention The main objective of this invention is to provide a method, system, device, and storage medium for vehicle-mounted CAN communication security verification, addressing the technical issue of how to improve the efficiency of automotive network security authentication.
[0006] To achieve the above objectives, the present invention provides a vehicle-mounted CAN communication security verification method, the vehicle-mounted CAN communication security verification method comprising: The DBC file of the vehicle under test is parsed, and multiple target CAN messages and the corresponding SecOC configuration information of each message are extracted from the parsed DBC file. Based on the TARA analysis results and the SecOC configuration information, attack test cases are constructed for each target CAN message. Based on the attack test case, malicious messages were injected into the CAN bus of the vehicle under test; Real-time acquisition of the target ECU's interception status information of the malicious message and security event log trigger information; Based on preset regulatory standards, the interception status information and the security event log trigger information are analyzed for communication, and a structured test report is generated based on the analysis results.
[0007] Optionally, before constructing the attack test case corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information, the method further includes: Determine the vehicle model information of the vehicle to be tested; Based on the vehicle model information, a TARA analysis was performed on the vehicle under test to obtain the TARA analysis results.
[0008] Optionally, the step of constructing attack test cases corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information includes: Based on the TARA analysis results, identify the threat scenarios corresponding to each target CAN message; Based on the threat scenario, attack test cases are constructed for each target CAN message according to the SecOC configuration information. The different attack types include replay attack type, FV tampering type and MAC forgery type.
[0009] Optionally, the step of constructing attack test cases for each target CAN message based on the threat scenario and the SecOC configuration information includes: Determine the corresponding attack vector and attack path based on the threat scenario; Based on the attack vector, the attack path, and the SecOC configuration information, attack test cases are constructed for each target CAN message.
[0010] Optionally, injecting malicious messages into the CAN bus of the vehicle under test based on the attack test case includes: Construct malicious packets based on the aforementioned attack test cases; In a real vehicle environment or a simulation environment, the test system is connected to the CAN bus interface of the vehicle under test via the PeakCAN USB-CAN interface card; The can.send() function is called to send the malicious message to the CAN bus of the vehicle under test.
[0011] Optionally, constructing a malicious message based on the attack test case includes: Determine the associated message information and corresponding SecOC configuration information based on the attack test cases; A pre-defined standard CAN data frame basic framework is constructed based on the associated message information and the corresponding SecOC configuration information. Malicious messages are constructed based on the CAN data frame framework of the preset standard and the tampering operations of the corresponding attack types.
[0012] Optionally, sending the malicious message to the CAN bus of the vehicle under test includes: According to the preset injection timing rules, the malicious message is sent to the CAN bus of the vehicle under test.
[0013] Furthermore, to achieve the above objectives, the present invention also proposes an in-vehicle CAN communication security verification system, the in-vehicle CAN communication security verification system comprising: The system includes: The communication configuration parsing module is used to parse the DBC file of the vehicle under test and extract multiple target CAN messages and the corresponding SecOC configuration information from the parsed DBC file. The security policy construction module is used to construct attack test cases corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information. An automated attack injection module is used to inject malicious messages into the CAN bus of the vehicle under test based on the attack test cases. The security response monitoring module is used to collect the interception status information of the target ECU to the malicious message and the security event log trigger information in real time; The test report generation module is used to perform communication analysis on the interception status information and the security event log trigger information based on preset regulatory standards, and generate a structured test report based on the analysis results.
[0014] Furthermore, to achieve the above objectives, the present invention also proposes an in-vehicle CAN communication security verification device, the device comprising: a memory, a processor, and an in-vehicle CAN communication security verification program stored in the memory and executable on the processor, the in-vehicle CAN communication security verification program being configured to implement the steps of the in-vehicle CAN communication security verification method described above.
[0015] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing an in-vehicle CAN communication security verification program, wherein the in-vehicle CAN communication security verification program, when executed by a processor, implements the steps of the in-vehicle CAN communication security verification method described above.
[0016] This invention first parses the DBC file of the vehicle under test and extracts multiple target CAN messages and the corresponding SecOC configuration information from the parsed DBC file. Based on the TARA analysis results and the SecOC configuration information, attack test cases are constructed for each target CAN message. Then, based on the attack test cases, malicious messages are injected into the CAN bus of the vehicle under test. Subsequently, the interception status information of the target ECU and the trigger information of security event logs are collected in real time. Based on preset regulatory standards, communication analysis is performed on the interception status information and the trigger information of security event logs to generate a structured test report. This invention can automatically complete the effectiveness test of the SecOC security mechanism, support confidentiality and integrity verification, and automatically generate compliance evidence, improving the efficiency of automotive network security certification. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating the first embodiment of the vehicle-mounted CAN communication security verification method of the present invention. Figure 2 This is a structural block diagram of the first embodiment of the vehicle-mounted CAN communication security verification system of the present invention.
[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.
[0020] This invention provides a method for verifying the security of vehicle-mounted CAN communication, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the vehicle-mounted CAN communication security verification method of the present invention.
[0021] In this embodiment, the vehicle-mounted CAN communication security verification method includes the following steps: S1 parses the DBC file of the vehicle under test and extracts multiple target CAN messages and the corresponding SecOC configuration information from the parsed DBC file.
[0022] It is easy to understand that the execution subject of this embodiment can be an in-vehicle CAN communication security verification system with functions such as data processing, network communication and program execution, or other computer devices with similar functions. This embodiment does not limit it.
[0023] By integrating cantools (DBC file parsing), python-can (CAN bus communication control), and cryptography (Message Authentication Code (MAC) algorithm verification) into a single Python framework, test breakpoints caused by switching between multiple tools are avoided, thus improving the completeness of verification.
[0024] In its implementation, the system first automatically reads the DBC file of the vehicle under test through the integrated cantools library, and parses all CAN communication parameters, including the arbitration ID (11-bit standard ID / 29-bit extended ID), DLC (Data Length Code), data field format, transmission cycle, and ECU of all messages. Then, it combines the DBC parsing results with user-defined or pre-marked "protected" key CAN messages (i.e., target CAN messages, such as Battery_Status message ID=0x2A0, etc.). After that, it extracts the complete Secure Onboard Communication (SecOC) configuration for each target message from the extended fields of the DBC file, including: Authenticator length, FV field position / bits, MAC algorithm type (such as CMAC), key verification rules, and message freshness update cycle.
[0025] S2. Based on the TARA analysis results and the SecOC configuration information, construct attack test cases corresponding to each target CAN message.
[0026] It should be understood that the vehicle model information (i.e., vehicle model-related information) of the vehicle to be tested needs to be determined in advance. Based on the vehicle model information, the cybersecurity team conducts a Threat Analysis and Risk Assessment (TARA) analysis on the vehicle to be tested to obtain the TARA analysis results.
[0027] Furthermore, based on the TARA analysis results, the threat scenarios corresponding to each target CAN message are identified; based on the threat scenarios, the corresponding attack vectors and attack paths are determined; and based on the attack vectors, attack paths, and SecOC configuration information, attack test cases corresponding to each target CAN message are constructed.
[0028] It should be noted that if the threat scenario is that the attacker can record and replay legitimate messages to deceive the receiving ECU, then the corresponding attack test case is a replay attack test case; if the threat scenario is that the attacker can tamper with the Fresh Value (FV) in the message to bypass replay detection, then the corresponding attack test case is an FV tampering attack test case; if the threat scenario is that the attacker can forge the Message Authentication Code (MAC) to inject illegal instructions, then the corresponding attack test case is a MAC forgery attack test case.
[0029] In practical implementation, if the threat scenario is that the attacker can record and replay legitimate messages to deceive the receiving ECU, then it is necessary to break down the threat scenario and describe the complete sequence of steps from "initiating an attack" to "achieving the goal". The corresponding attack path is: ① The attacker records legitimate CAN messages through a bus monitoring tool → ② The attacker stores the recorded message data → ③ The attacker retransmits the recorded message to the CAN bus at an appropriate time → ④ The receiving ECU misjudges the message as legitimate and executes the corresponding instruction.
[0030] It should also be noted that the same attack path may contain one or more attack vectors, and different attack paths may reuse the same attack vector. For example, in the threat scenario described above, where "an attacker can record and replay legitimate messages to deceive the receiving ECU," the attack vector of the attack path is "retransmit the recorded legitimate message to the CAN bus (retransmit after a delay of ≥1 message cycle)." In the threat scenario where "an attacker can tamper with the Fresh Value (FV) in the message to bypass replay detection," the attack vector of the attack path is "tamper with the FV field value in the CAN message (e.g., decrement by 1, set to a historical value)." In the threat scenario where "an attacker can forge the Message Authentication Code (MAC) to inject illegal instructions," the attack vector of the attack path is "specify an invalid key (e.g., an all-zero key) and set the forged MAC calculation rules according to the MAC algorithm configured in SecOC."
[0031] The parameters of the SecOC configuration information include the FV field position / bit length, MAC algorithm type (such as CMAC), security field (FV+MAC) distribution, packet ID, DLC length, etc. For example, for a Battery_Status packet with ID=0x2A0, the SecOC configuration information for a replay attack can be "DLC=8, sending period=500ms"; the SecOC configuration information for an FV tampering attack can be "FV field=bytes 5-6 (16 bits), DLC=8"; and the SecOC configuration information for a MAC spoofing attack can be "MAC field=bytes 7-8, using CMAC algorithm, payload=first 4 bytes".
[0032] It should also be noted that the role of SecOC configuration information is: ① to provide precise parameters (such as field position and algorithm type) for the landing of attack vectors, ensuring that the attack can hit the core of SecOC protection; ② to provide compliance basis for the construction of test cases (such as message ID and DLC length), ensuring that malicious messages comply with the CAN bus protocol and SecOC format requirements; ③ to provide a benchmark for judging expected results (such as the ECU should detect anomalies and discard messages based on SecOC rules).
[0033] S3. Based on the attack test case, inject malicious messages into the CAN bus of the vehicle under test.
[0034] Using the attack test cases’ “attack type, tampering rules, and injection requirements” as core instructions, combined with SecOC configuration information extracted from DBC files (such as message ID, field position, algorithm type, etc.), and following the ISO 11898 CAN bus standard, malicious messages that meet the format requirements and can accurately trigger SecOC protection detection are reverse-engineered.
[0035] Based on the message information associated with the test cases and the SecOC configuration information, a basic framework for CAN data frames conforming to a preset standard (such as ISO11898 standard) is first constructed to ensure format compliance. Arbitration ID: Fully reuses the target CAN message ID (e.g., 0x2A0) bound to the test case to ensure it can be recognized by the target ECU; DLC: Strictly match the DLC length of the original message (e.g., 8 bytes) to avoid the ECU directly filtering out the message due to abnormal length, which would render the test invalid. Initial structure of the data field: The data field is divided into partitions according to the SecOC configuration information, that is, "the first N bytes are the original payload + the last M bytes are the security fields (FV + MAC)". First, the payload and security field data of the original message are filled to form the "original message template".
[0036] Precise tampering is performed for different attack types to ensure the attack intent is realized. The tampering operations for three typical attack types are shown in the table below:
[0037] In this embodiment, after the tampering is completed, the malicious message needs to be format-verified to avoid invalid testing due to format errors. The key points of the verification are as follows: Basic format verification: The arbitration ID and DLC length are consistent with the original message and comply with the ISO 11898 standard; Field length verification: The length of the tampered FV / MAC field must be consistent with the SecOC configuration information (e.g., a 16-bit FV field must not be changed to 8 bits). Data type validation: Field data format conforms to CAN bus requirements (e.g., hexadecimal, no invalid byte padding); Attack accuracy verification: Only the fields specified in the test case are modified, while other fields remain in their original values to ensure that the attack target is singular, which facilitates the attribution analysis of the subsequent ECU response results.
[0038] It should also be understood that all tampering operations must match the SecOC configuration information (such as field position and algorithm type), otherwise SecOC protection detection cannot be triggered; the generated malicious packets must be associated with the arbitration ID one by one, and the field details before and after tampering must be recorded to facilitate the tracing and alignment of subsequent injection logs and ECU response results.
[0039] For a Battery_Status message with ID=0x2A0 and DLC=8, an example of a malicious message data field for a MAC forgery attack is: [Payload: 4 bytes][FV: 2 bytes][Fake_MAC: 2 bytes], where Fake_MAC = CMAC(Zero_Key,Payload || FV).
[0040] It should also be noted that, in a real vehicle environment or a simulation environment, the test system is connected to the CAN bus interface of the vehicle under test via the PeakCAN USB-CAN interface card; the can.send() function is called to send the malicious message to the CAN bus of the vehicle under test.
[0041] In practical implementation, the CAN channel should be initialized using the PCAN-Basic API or the python-can library, and the baud rate should be set (e.g., 500 kbps). Preset injection timing rules: Immediate injection: Send within 10ms after receiving the original message (simulating replay); Delayed injection: Send after a delay of T seconds after recording (simulating cross-cycle replay).
[0042] The entire injection process requires no modification to the ECU firmware and is achieved entirely through external bus operation, which complies with the principles of black-box testing.
[0043] S4, Real-time collection of the target ECU's interception status information of the malicious message and security event log trigger information.
[0044] The response behavior of target ECUs (such as in-vehicle gateways, IVI, connected T-boxes, and vehicle control units) is captured in real time using CAN bus monitoring tools, and the intercepted status information includes: Whether to discard malicious messages (manifested as no corresponding response message or failure to execute malicious message instructions); Should an error response code be returned? Check whether legitimate message communication is normal (to avoid bus congestion caused by malicious injection, which could affect the determination of test results).
[0045] The safety event log of the target ECU is retrieved using an on-board diagnostic tool or vehicle network management system. The safety event log trigger information includes: Log trigger time and event ID (e.g., 0x55 indicates MAC authentication failure); Event types (such as illegal message interception, FV verification failure, MAC authentication failure); Associated message ID, alarm level, and detailed log description; Log integrity (verify whether all malicious message injection attempts are covered).
[0046] S5. Based on preset regulatory standards, perform communication analysis on the interception status information and the security event log trigger information, and generate a structured test report based on the analysis results.
[0047] Based on the preset regulatory standards (i.e., GB 44495 and R155 requirements), determine whether the communication meets the following requirements: integrity: whether illegal messages are effectively intercepted by the target ECU; confidentiality: sensitive data is not transmitted in plaintext (for CAN messages involving sensitive data); freshness: whether the FV mechanism can effectively resist replay attacks and FV tampering attacks; log compliance: whether security events are fully recorded and whether the log information contains key elements (timestamp, message ID, event type).
[0048] Generate structured test reports: Output PDF / JSON format reports containing test items, attack types, expected results, actual results, and compliance conclusions, supporting CSMS auditing.
[0049] In practice, only low-cost USB-CAN devices such as PeakCAN are needed to complete SecOC validity verification, without the need for Vector series or dedicated HIL benches, which significantly reduces the compliance testing threshold for small and medium-sized enterprises.
[0050] In this embodiment, the DBC file of the vehicle under test is first parsed, and multiple target CAN messages and the corresponding SecOC configuration information for each message are extracted from the parsed DBC file. Attack test cases are constructed for each target CAN message based on the TARA analysis results and the SecOC configuration information. Then, based on the attack test cases, malicious messages are injected into the CAN bus of the vehicle under test. Subsequently, the interception status information of the target ECU and the security event log trigger information are collected in real time. Communication analysis is performed on the interception status information and security event log trigger information based on preset regulatory standards to generate a structured test report. This embodiment can automatically complete the effectiveness test of the SecOC security mechanism, support confidentiality and integrity verification, and automatically generate compliance evidence, improving the efficiency of automotive network security certification.
[0051] Reference Figure 2 , Figure 2 This is a structural block diagram of the first embodiment of the vehicle-mounted CAN communication security verification system of the present invention.
[0052] like Figure 2As shown, the vehicle-mounted CAN communication security verification system proposed in this embodiment of the invention includes: The communication configuration parsing module 2001 is used to parse the DBC file of the vehicle under test and extract multiple target CAN messages and the corresponding SecOC configuration information from the parsed DBC file. The security policy construction module 2002 is used to construct attack test cases corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information. The automated attack injection module 2003 is used to inject malicious messages into the CAN bus of the vehicle under test based on the attack test cases. The security response monitoring module 2004 is used to collect the interception status information of the target ECU to the malicious message and the security event log trigger information in real time; The test report generation module 2005 is used to perform communication analysis on the interception status information and the security event log trigger information based on preset regulatory standards requirements, and generate a structured test report based on the analysis results.
[0053] Other embodiments or specific implementations of the vehicle-mounted CAN communication security verification system of the present invention can be referred to the above-described method embodiments, and will not be repeated here.
[0054] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0055] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0056] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0057] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.
Claims
1. A method for verifying the security of vehicle-mounted CAN communication, characterized in that, The method includes the following steps: The DBC file of the vehicle under test is parsed, and multiple target CAN messages and the corresponding SecOC configuration information of each message are extracted from the parsed DBC file. Based on the TARA analysis results and the SecOC configuration information, attack test cases are constructed for each target CAN message. Based on the attack test case, malicious messages were injected into the CAN bus of the vehicle under test; Real-time acquisition of the target ECU's interception status information of the malicious message and security event log trigger information; Based on preset regulatory standards, the interception status information and the security event log trigger information are analyzed for communication, and a structured test report is generated based on the analysis results.
2. The method according to claim 1, characterized in that, Before constructing the attack test cases corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information, the process also includes: Determine the vehicle model information of the vehicle to be tested; Based on the vehicle model information, a TARA analysis was performed on the vehicle under test to obtain the TARA analysis results.
3. The method as described in claim 1, characterized in that, The step of constructing attack test cases for each target CAN message based on the TARA analysis results and the SecOC configuration information includes: Based on the TARA analysis results, identify the threat scenarios corresponding to each target CAN message; Based on the threat scenario, attack test cases are constructed for each target CAN message according to the SecOC configuration information.
4. The method as described in claim 3, characterized in that, The attack test cases for each target CAN message are constructed based on the threat scenario and the SecOC configuration information, including: Determine the corresponding attack vector and attack path based on the threat scenario; Based on the attack vector, the attack path, and the SecOC configuration information, construct attack test cases corresponding to each target CAN message.
5. The method as described in claim 1, characterized in that, The injection of malicious messages into the CAN bus of the vehicle under test based on the attack test case includes: Construct malicious packets based on the aforementioned attack test cases; In a real vehicle environment or a simulation environment, the test system is connected to the CAN bus interface of the vehicle under test via the PeakCAN USB-CAN interface card; The can.send() function is called to send the malicious message to the CAN bus of the vehicle under test.
6. The method as described in claim 5, characterized in that, The construction of malicious packets based on the attack test cases includes: Determine the associated message information and corresponding SecOC configuration information based on the attack test cases; A pre-defined standard CAN data frame basic framework is constructed based on the associated message information and the corresponding SecOC configuration information. Malicious messages are constructed based on the CAN data frame framework of the preset standard and the tampering operations of the corresponding attack types.
7. The method as described in claim 5, characterized in that, Sending the malicious message to the CAN bus of the vehicle under test includes: According to the preset injection timing rules, the malicious message is sent to the CAN bus of the vehicle under test.
8. A vehicle-mounted CAN communication security verification system, characterized in that, The system includes: The communication configuration parsing module is used to parse the DBC file of the vehicle under test and extract multiple target CAN messages and the corresponding SecOC configuration information from the parsed DBC file. The security policy construction module is used to construct attack test cases corresponding to each target CAN message based on the TARA analysis results and the SecOC configuration information. An automated attack injection module is used to inject malicious messages into the CAN bus of the vehicle under test based on the attack test cases. The security response monitoring module is used to collect the interception status information of the target ECU to the malicious message and the security event log trigger information in real time; The test report generation module is used to perform communication analysis on the interception status information and the security event log trigger information based on preset regulatory standards, and generate a structured test report based on the analysis results.
9. A vehicle-mounted CAN communication security verification device, characterized in that, The device includes: a memory, a processor, and an in-vehicle CAN communication security verification program stored in the memory and executable on the processor, the in-vehicle CAN communication security verification program being configured to implement the steps of the in-vehicle CAN communication security verification method as described in any one of claims 1 to 7.
10. A storage medium, characterized in that, The storage medium stores an in-vehicle CAN communication security verification program, which, when executed by a processor, implements the steps of the in-vehicle CAN communication security verification method as described in any one of claims 1 to 7.