A security testing method for vehicle charging interface information

Abstract

The present invention relates to the technical field of vehicle testing, and particularly to a security testing method for vehicle charging interface information. Normal and forged charging demand messages are sent to the vehicle to be tested, and the demand response results of the vehicle to be tested are obtained; the vehicle to be tested is charged, and normal signal data and forged signal data during the charging process are sent, and the charging feedback information of the vehicle to be tested is collected; a forged charging interruption operation is performed on the vehicle to be tested, a forged charging abort message is sent, and the charging abort response result of the vehicle to be tested is obtained; an invalid message is sent to the vehicle to be tested for testing, and the charging system stability and time verification ability of the vehicle to be tested are obtained; the comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data is evaluated, and a security assessment report is output. The present invention can effectively evaluate the comprehensive performance of the vehicle and the charging pile under different attacks and forged data, and efficiently form a complete security assessment report.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle testing, and particularly to a security testing method for vehicle charging interface information. Background Art

[0002] With the popularization of intelligent vehicles, the networking level of vehicles is continuously increasing, and vehicle external interfaces (such as charging interfaces, vehicle-mounted communication interfaces, etc.) are becoming increasingly complex.

[0003] These interfaces not only need to meet the charging requirements, but also involve various functions such as software updates and data transmission, which pose challenges to security supervision. Therefore, it is necessary to carry out compliance testing for forming access control protection for the charging interface and prohibiting unauthorized access. Summary of the Invention

[0004] To achieve the above object, the present invention provides the following technical solutions:

[0005] According to the first aspect of the present invention, the present invention claims protection for a security testing method for vehicle charging interface information, including:

[0006] Sending a normal charging demand message and a forged charging demand message to the vehicle to be tested, and obtaining the demand response result of the vehicle to be tested;

[0007] Charging the vehicle to be tested, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle to be tested, and collecting the charging feedback information of the vehicle to be tested;

[0008] Performing a forged charging interruption operation on the vehicle to be tested, sending a forged charging termination message, and obtaining the charging termination response result of the vehicle to be tested;

[0009] Sending an invalid message to the vehicle to be tested for DDoS testing and time synchronization testing, and obtaining the charging system stability and time verification ability of the vehicle to be tested;

[0010] Evaluating the comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data according to the demand response result, charging feedback information, charging termination response result, charging system stability and time verification ability, and outputting a security assessment report.

[0011] Further, the step of sending a normal charging demand message and a forged charging demand message to the vehicle to be tested, and obtaining the demand response result of the vehicle to be tested, further includes:

[0012] Before charging starts, the vehicle to be tested sends a charging demand and charging mode data to the charging pile, and first captures a normal charging demand message to determine the response mechanism of the vehicle to changes in charging demand;

[0013] After capturing the normal charging demand data, the tester constructs a forged charging demand message and sends it to the charging pile to observe the response of the vehicle to the forged charging demand message.

[0014] Furthermore, for charging the vehicle under test, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle under test, and collecting the charging feedback information of the vehicle under test, further includes:

[0015] After the charging starts, the vehicle under test periodically sends a normal temperature data message of the battery, and the tester captures and analyzes the normal temperature data message;

[0016] Send forged temperature data to obtain whether the vehicle under test will wrongly adjust the charging parameters or start the cooling system;

[0017] During the charging process, the vehicle under test and the charging pile exchange charging status data. The tester forges the status data of the vehicle's entire EVCC module and sends false status information to the charging pile to verify the vehicle under test's abnormal handling ability in the face of forged status data;

[0018] Periodically send forged charging status data to the vehicle under test to obtain the response of the vehicle under test.

[0019] Furthermore, forging a charging interruption operation on the vehicle under test, sending a forged charging interruption message, and obtaining the charging interruption response result of the vehicle under test, further includes:

[0020] During the charging process, the tester forges a message to stop charging and sends a false stop charging signal to the vehicle under test;

[0021] Collect the reaction of the vehicle under test after receiving the false stop charging signal, whether it immediately stops charging or whether it recognizes the forged signal and continues charging.

[0022] Furthermore, sending invalid messages to the vehicle under test for DDoS testing and time synchronization testing, and obtaining the charging system stability and time verification ability of the vehicle under test, further includes:

[0023] Before and during the charging process, the tester sends multiple invalid messages to the vehicle and the charging pile to test the anti-DDoS attack ability;

[0024] Collect the performance of the charging system of the vehicle under test in the face of a high flow of invalid messages, including response time, charging interruption situation, and fault alarm;

[0025] During the charging parameter configuration phase, the vehicle to be tested completes parameter configuration and periodically sends time data to the charging pile. The tester forges the time data in compressed and uncompressed formats to deceive the vehicle to be tested into performing time configuration;

[0026] Collect whether errors occur in the vehicle to be tested after receiving the forged time data, including the accuracy of the charging log records.

[0027] Further, evaluating the comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data based on the demand response result, charging feedback information, charging interruption response result, charging system stability, and time verification ability, and outputting a security assessment report, further includes:

[0028] CAN configuration information, at least including: serial number, channel, arbitration bit rate, source address, destination address, padding;

[0029] Startup test running parameters, at least including: connection timeout, send timeout, receive timeout, pre-test case delay, maximum send rate of test cases, message interval of test cases, number of retries when initialization fails, action after all initializations fail;

[0030] Task stop conditions, at least including: task running time, number of test cases, number of abnormal cases;

[0031] Interoperability test running parameters, at least including: connection timeout, send timeout, receive timeout, pre-interoperability test delay, message interval of interoperability test, number of retries when connection fails;

[0032] Packet capture settings, at least including: whether to enable packet capture, IP address, port;

[0033] Periodic message configuration, at least including: whether to send periodic messages, CAN ID, EFF ID, DATA, period, whether to enable packet capture, IP address, port;

[0034] Receive filter rules, at least including: whether to set receive filter rules, CAN ID, MASK, EFF ID;

[0035] Probe case configuration, at least including: whether to enable the monitor, pre-probe case delay, number of probe case retries, probe case timeout, probe case frequency, probe case interval, number of consecutive probe case failures, consecutive probe case failure time;

[0036] External command configuration, including at least: whether to enable the monitor, execute before the task starts, execute before each test case starts, execute after each test case ends, execute when the test case fails, execute after the task ends, and execute when detecting the target status;

[0037] Engine mode, including at least mutation mode, field combination mutation mode, number of field combination mutations, and frame combination mode.

[0038] Furthermore, the method further includes:

[0039] When the vehicle to be tested is starting to charge, forge in-vehicle data, forge a data message for stopping charging, and detect whether the vehicle to be tested can recognize the forged data to deceive the vehicle to be tested into stopping charging;

[0040] When the vehicle to be tested is stopped charging, deceive the vehicle to be tested into starting to charge.

[0041] Furthermore, when the method deceives the vehicle to be tested into starting to charge when the vehicle to be tested is stopped charging, it further includes:

[0042] The charging data collector is respectively connected to the charging port and the charging gun of the vehicle to be tested, scans or swipes the card to start charging, stops charging after about a preset duration, constructs test data, and deceives the vehicle into starting to charge;

[0043] Obtain the message difference of the vehicle to be tested at the start and stop of charging. Based on the message difference, use the charging data collector to construct a simulated message to simulate the charging pile to resend a start charging command to the vehicle;

[0044] Observe whether the vehicle responds to the forged start charging message and whether it re-enters the charging state;

[0045] If the vehicle to be tested restarts charging, it means that the system does not have a sufficient security verification mechanism and accepts the forged start signal;

[0046] If the vehicle to be tested ignores the forged start charging message, it indicates that the vehicle has a security verification mechanism to prevent unauthorized restart of charging;

[0047] The security verification mechanism of the vehicle to be tested for the forged message includes using message freshness verification, handshake verification, and timestamp verification to prevent unauthorized charging start;

[0048] If the vehicle to be tested verifies the message freshness, it rejects outdated or repeated start commands.

[0049] During handshake verification, a new handshake is required to confirm the safety status. If the forged message lacks key handshake information, the vehicle will refuse to recharge.

[0050] Furthermore, the method further comprises:

[0051] During the charging handshake phase, the protocol stack version data is forged to verify the vehicle protocol stack's ability to handle exceptions;

[0052] Using the charging data collector, capturing all handshake messages exchanged between the vehicle to be tested and the charging pile during the charging handshake phase, wherein the version number contained in the handshake message is used to ensure the communication compatibility between the charging pile and the vehicle to be tested;

[0053] By forging the version number or modifying the function bit to construct forged protocol stack version data, during the handshake phase, the forged protocol stack version data is inserted through the charging data collector to simulate inconsistent or erroneous protocol version information sent by the charging pile;

[0054] Obtaining whether the vehicle to be tested starts charging normally or reports an error after receiving the forged protocol stack version data;

[0055] If the vehicle to be tested has a version verification mechanism, charging is refused and an error of protocol version mismatch is reported;

[0056] If the vehicle to be tested does not have a valid verification mechanism, charging is started but abnormal behavior occurs or charging is stopped.

[0057] According to a second aspect of the present invention, the present invention claims protection for a safety testing system for vehicle charging interface information, comprising:

[0058] one or more processors;

[0059] A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the safety testing method for vehicle charging interface information.

[0060] The beneficial effects of the present invention are:

[0061] Ensure that the charging system remains operational and safe when subjected to a denial of service attack by observing the system's performance when faced with a high volume of invalid messages;

[0062] Verify the vehicle's safety mechanisms and exception handling capabilities to ensure it can effectively identify and reject false charging stop requests;

[0063] Effectively verify whether the vehicle has a strong time synchronization mechanism by observing whether the vehicle makes an error after receiving forged time data, and ensure that it can make a reasonable response when receiving abnormal time data;

[0064] Through a series of tests, integrate the results of each link, evaluate the safety, stability and robustness of the charging system, effectively evaluate the comprehensive performance of the vehicle and the charging pile under different attacks and forged data, and efficiently form a complete security assessment report. Brief Description of the Drawings

[0065] Figure 1 It is a flowchart of a security test method for vehicle charging interface information requested to be protected by the embodiments of the present invention.

[0066] Figure 2 It is a data flow diagram of a security test method for vehicle charging interface information requested to be protected by the embodiments of the present invention. Detailed Embodiments

[0067] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0068] The terms "first", "second", and "third" in the present invention are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first", "second", and "third" may explicitly or implicitly include at least one of such features. In the description of the present invention, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically defined. All directional indications (such as up, down, left, right, front, back...) in the embodiments of the present invention are only used to explain the relative positional relationship and movement conditions between components in a specific posture (as shown in the drawings). If the specific posture changes, the directional indications will also change accordingly. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products, or devices.

[0069] Reference to an "embodiment" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0070] The test software and hardware tools of the embodiment of the present invention meet the following indicators:

[0071] a) The hardware adaptation tool should have portable instruments and equipment applied to the national standard DC charging and discharging process of electric vehicles, which can collect, store, analyze and diagnose the charging voltage, charging and discharging current, auxiliary source voltage, auxiliary source current, CC1 voltage, CC2 voltage, gun tip DC+ and DC- temperature, gun seat DC+ and DC- temperature during the DC charging process.

[0072] b) The hardware adapter tool requires that the DC charge and discharge voltage and current acquisition ranges are at least 0~1000V and 0~250A respectively, with a sampling accuracy of 0.5%FS. The plug and socket temperature is -50℃~150℃, with an accuracy of ±1℃.

[0073] c) The hardware adaptation tool should be able to directly connect to the host computer software through a wiring harness to perform real-time online analysis and diagnosis, and can set the message forwarding frequency.

[0074] d) The hardware adaptation tool should be able to detect vehicle-pile messages and real-time data, and identify charging faults and fault sources. When in the charging process, the charging diagnosis page displays the current charging stage of the device (handshake, configuration, charging, end), and automatically displays the diagnosis results after charging is completed. Detailed diagnosis results are generated and stored on the SD card, which users can export for viewing. The screen displays the reason for charging shutdown, shutdown fault, and shutdown error. The detailed diagnostic report includes four major categories: charging overview, shutdown cause diagnosis, compliance diagnosis, and charging information, and each category has specific diagnostic information.

[0075] e) The host computer software tool should be able to adapt the charging protocol to communicate with the vehicle charging interface.

[0076] f) The test cases provided by the host computer software tool need to cover real charging pile (man-in-the-middle) attack cases and simulated charging pile attack cases.

[0077] g) The host computer software tool should be able to customize and construct standard charging protocol message templates.

[0078] h) After the upper computer software is evaluated, it can automatically generate a test report to show the failed use cases and related interaction processes.

[0079] According to the first embodiment of the present invention, the present invention claims a security testing method for vehicle charging interface information. Referring to Figure 1 , it includes:

[0080] Sending normal charging demand messages and forged charging demand messages to the vehicle to be tested, and obtaining the demand response result of the vehicle to be tested;

[0081] Charging the vehicle to be tested, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle to be tested, and collecting the charging feedback information of the vehicle to be tested;

[0082] Performing a forged charging interruption operation on the vehicle to be tested, sending a forged charging interruption message, and obtaining the charging interruption response result of the vehicle to be tested;

[0083] Sending invalid messages to the vehicle to be tested for DDoS testing and time synchronization testing, and obtaining the charging system stability and time verification ability of the vehicle to be tested;

[0084] Evaluating the comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data according to the demand response result, charging feedback information, charging interruption response result, charging system stability and time verification ability, and outputting a security assessment report.

[0085] Furthermore, the step of sending normal charging demand messages and forged charging demand messages to the vehicle to be tested and obtaining the demand response result of the vehicle to be tested further includes:

[0086] Before charging starts, the vehicle to be tested sends charging demand and charging mode data to the charging pile. First, capture the normal charging demand message to determine the vehicle's response mechanism to changes in charging demand;

[0087] After capturing the normal charging demand data, the tester constructs a forged charging demand message and sends it to the charging pile to observe the vehicle's response to the forged charging demand message.

[0088] Among them, in this embodiment, during the vehicle charging stage, the forged vehicle periodically sends charging demand and charging mode data to the charging pile to test the vehicle's handling ability after changing the battery demand.

[0089] Regarding the scenario setting and the initial conditions, the charging demand and mode are summarized as follows: during the charging process, the vehicle will periodically send charging demand messages to the charging pile according to the battery demand, reporting parameters such as the required charging current, voltage, and power. The charging mode may include constant voltage charging mode (CV) and constant current charging mode (CC), and these modes determine how to adjust the charging parameters according to the current state of the battery.

[0090] The charging requirements of a vehicle usually depend on the current state of the battery (such as charge level, temperature, state of health), and these requirements change continuously during the charging process to ensure the safety and efficiency of the charging process.

[0091] The test objective is to send false information to the charging pile by forging the charging requirements and charging mode data of the vehicle, and to test how the vehicle handles abnormal changes in the charging mode after the battery requirements change. Examine whether the vehicle can make correct responses based on the forged charging requirements and mode data, especially when the battery requirements do not match the actual situation.

[0092] When capturing and analyzing messages, it is first necessary to capture normal charging requirement messages. During the vehicle charging stage, use a charging data collector to capture and record the charging requirement messages periodically sent by the vehicle, including demand data such as current, voltage, and power. At the same time, capture the charging mode messages sent by the vehicle, record whether the vehicle is in the constant voltage charging mode (CV) or the constant current charging mode (CC) currently, and analyze how these modes affect the adjustment of charging parameters.

[0093] When analyzing the charging requirement data structure, analyze the captured message structure to determine the key fields in the charging requirement data:

[0094] Voltage requirement: The current charging voltage required by the vehicle.

[0095] Current requirement: The current charging current required by the vehicle.

[0096] Power requirement: The charging power requirement reported by the vehicle (usually the product of voltage and current).

[0097] Charging mode: An identifier indicating whether the vehicle is in the constant voltage mode or the constant current mode.

[0098] When constructing forged charging requirements and mode messages, it is first necessary to forge charging requirement messages, including current / voltage forgery: Construct false charging requirement data and send forged too high or too low current / voltage requirements to the charging pile. For example, when the battery state is close to full, forge a higher current requirement, or when the battery is close to depletion, forge a lower voltage requirement.

[0099] Power forgery: Construct a forged message for power requirement and send an unreasonable power requirement (such as a power value much higher than the current bearing capacity of the battery).

[0100] Faking a charging mode switch during the forgery of charging mode messages: During normal charging, a vehicle usually switches between different charging modes (e.g., from constant current mode to constant voltage mode). Forge the messages for this mode switch and send a false charging mode switch signal to the charging pile to test the vehicle's response ability when the charging mode suddenly changes. During the constant voltage / constant current mode interference, when forging that the vehicle is in the constant voltage mode, send a false message in the constant current mode, or vice versa, to simulate a mode switch that does not meet the actual requirements by forging messages.

[0101] After that, send the forged messages and detect the vehicle's response, including periodically sending forged charging demand and mode data:

[0102] During the charging process, use a data acquisition instrument to construct forged charging demand messages and send these forged data periodically. Ensure that these forged current, voltage, and power demands are inconsistent with the vehicle's actual demands.

[0103] Forging charging mode data (such as suddenly switching the charging mode) and sending it regularly to observe the vehicle's reaction to the mode change.

[0104] When detecting the vehicle's response under abnormal conditions, observe whether the vehicle exhibits abnormal behavior after receiving the forged charging demand and mode data, including:

[0105] Adjustment error: Will the vehicle wrongly adjust the battery charging parameters (such as current, voltage)?

[0106] Error alarm: Will it generate a false fault alarm to indicate the abnormal state during the charging process?

[0107] Safety mechanism activation: Can the vehicle detect the forged data and trigger the protection mechanism to stop charging or switch to the safe mode?

[0108] During the verification of the vehicle's handling ability, conduct a charging demand verification, including whether the vehicle can detect the forged charging demand data? For example, if the current charging demand of the battery is inconsistent with the forged data, will the vehicle ignore the forged data and continue to adjust the charging parameters according to the actual demand?

[0109] During the charging mode verification, when receiving the forged charging mode switch data, will the vehicle wrongly switch the charging mode, or will it detect that the mode switch does not match the battery state and maintain the current mode?

[0110] During the safety mechanism and fault handling, during the process where the forged data affects the charging, does the vehicle have a strong fault handling mechanism? If the forged charging demand or mode causes abnormal behavior, can the vehicle promptly abort the charging and record the abnormal log?

[0111] Defense measures and security enhancement suggestions are put forward, including a verification mechanism for charging requirements. For example, after receiving a charging requirement message, the vehicle should have a strong verification mechanism to ensure that the requirement data in the message matches the actual requirements of the battery. The rationality of the charging requirement can be verified through a multiple detection mechanism;

[0112] Mode switch verification, including the switch of the charging mode. The vehicle should have a complete state machine verification mechanism. In the mode switch message, the rationality of the mode switch should be verified through multiple aspects such as the current state of the battery and the charging stage to avoid misoperation.

[0113] Abnormal detection and automatic protection. For example, if an unreasonable charging requirement or charging mode switch message is received, the vehicle should have an automatic detection and protection mechanism. When a potential security threat is detected, the protection mechanism should be triggered to immediately stop charging and record a log to ensure the safety of the charging process.

[0114] For application scenarios, including security tests for public charging stations: Ensure that the vehicle does not have security hazards due to forged requirement messages in public charging stations; Security guarantee for home charging: Test whether the vehicle can automatically detect and protect the charging process when encountering forged charging requirements during home charging; Fleet charging management: During the centralized charging process of the fleet, ensure that each vehicle can correctly respond to the charging requirement and avoid charging anomalies caused by forged data.

[0115] Furthermore, charging the vehicle to be tested, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle to be tested, and collecting the charging feedback information of the vehicle to be tested further includes:

[0116] After the charging starts, the vehicle to be tested periodically sends a normal temperature data message of the battery, and the tester captures and analyzes the normal temperature data message;

[0117] Send forged temperature data to obtain whether the vehicle to be tested will incorrectly adjust the charging parameters or start the cooling system;

[0118] During the charging process, the vehicle to be tested and the charging pile exchange charging status data. The tester forges the status data of the vehicle's entire vehicle EVCC (charging management) module and sends false status information to the charging pile to verify the vehicle to be tested's abnormal handling ability in the face of forged status data;

[0119] Periodically send forged charging status data to the vehicle to be tested to obtain the response of the vehicle to be tested.

[0120] Among them, in this embodiment, the status data of the vehicle's entire vehicle EVCC (charging management) module includes data messages such as the current vehicle not being in the P gear and not having a charging status.

[0121] During the power battery temperature test, it is necessary to forge the vehicle battery temperature data during the vehicle charging process.

[0122] For the scenario setting and initial conditions, it is first necessary to determine the importance of the battery temperature during charging. During the charging process of an electric vehicle, the temperature of the power battery is a key factor affecting charging safety and efficiency. Too high or too low battery temperature will affect the charging performance and may even cause safety problems. The vehicle and the charging pile will regularly exchange the battery temperature data so that the charging pile can dynamically adjust the charging parameters (such as current, voltage) or trigger the cooling system according to the battery temperature.

[0123] The test objective is to send false temperature information to the charging pile or the vehicle by forging the temperature data of the power battery, so as to test the vehicle's response and processing ability to the forged temperature data; observe whether the vehicle will wrongly adjust the charging parameters based on the forged temperature information or trigger the wrong safety mechanism in case of abnormal temperature.

[0124] After that, message capture and analysis are carried out. Capture the battery temperature data message. During the charging process, the vehicle will regularly report the battery temperature data to the charging pile through the data bus (such as CAN bus). Use a charging data collector to capture and record these messages and analyze the temperature-related fields. These data may include information such as the average temperature of the battery, the highest temperature of a single battery, the lowest temperature of a single battery, and the status of the cooling system.

[0125] When analyzing the temperature message structure, by analyzing the message structure of the temperature data, determine the meaning of each field. The fields include:

[0126] Average temperature: The average temperature of the entire battery pack, usually in degrees Celsius.

[0127] Highest / Lowest single cell temperature: Record the temperatures of the single cells with the highest and lowest temperatures in the battery pack.

[0128] Cooling system status: An identifier indicating whether the cooling system is enabled or needs to be started.

[0129] When constructing forged battery temperature data, it includes constructing overly high temperature data: Construct forged temperature data and send false temperature information much higher than the actual battery temperature to the charging pile. For example, the forged temperature data can be a value of 85°C or higher to simulate the situation of battery overheating;

[0130] Similarly, it is possible to forge overly low temperature data and send false information lower than the actual temperature to the charging pile, such as **-20°C**, to simulate the situation of battery overcooling.

[0131] Forging the maximum or minimum temperature of a single battery when modifying the single battery temperature data. For example, during charging, forging the temperature of a single battery to be much higher than that of other batteries to trigger an abnormal response of the vehicle or charging pile.

[0132] When forging the cooling system status, constructing forged cooling system status data to simulate the status where the cooling system has been enabled or needs to be enabled, and sending error messages to the vehicle or charging pile, resulting in incorrect startup or shutdown of the cooling system.

[0133] After that, sending forged messages and detecting the vehicle response, including sending forged temperature data. During vehicle charging, use a data acquisition instrument to send forged temperature data messages to the vehicle and observe the vehicle's reaction to these forged data. For example, by sending overly high temperature data, simulate the state of battery overheating.

[0134] During charging, periodically send forged temperature data to simulate a gradual increase or decrease in temperature and test the vehicle's dynamic response to temperature changes.

[0135] When detecting the vehicle response, observe the vehicle's behavior after receiving the forged temperature data, especially the adjustment of charging parameters and the reaction of the cooling system:

[0136] Charging power adjustment: Will the vehicle reduce or increase the charging power based on the forged temperature data?

[0137] Cooling system response: Will the vehicle incorrectly start or shut down the cooling system based on the forged temperature data?

[0138] Fault alarm: Will the vehicle trigger a fault alarm and interrupt charging, especially when the forged temperature data indicates battery overheating or overcooling?

[0139] When verifying the vehicle's abnormal handling ability, it includes a data verification mechanism: Can the vehicle detect the forged temperature data? For example, when the forged temperature data seriously does not match the actual battery temperature, can the vehicle ignore these false data and continue to make decisions based on the actual temperature?

[0140] Regarding the system's response, if receiving overly high or low temperature data, will the vehicle's cooling system make an incorrect response? For example, will it incorrectly start the cooling system when the actual battery temperature is normal, or fail to start the cooling system when the battery is overheating?

[0141] Regarding the safety mechanism and charging interruption, does the vehicle have a perfect safety mechanism? When detecting abnormal temperature data, will the vehicle trigger the safety mechanism to immediately stop charging and record the abnormal log?

[0142] Regarding defense measures and security enhancement suggestions, the vehicle should have a strong temperature data verification mechanism to ensure that the received temperature data matches the actual battery temperature. The authenticity of temperature data can be verified through multi-sensor data fusion.

[0143] The vehicle should judge the reasonableness of temperature data based on the temperature change trend. A sudden sharp rise or fall in temperature may be an indication of forged data, and the vehicle should be able to identify these anomalies.

[0144] The cooling system should have an intelligent response mechanism to avoid making incorrect operations due to forged temperature data. Through a multi-level temperature detection and confirmation mechanism, the cooling system can still operate normally during a forged data attack.

[0145] By forging battery temperature data, the vehicle's processing ability and response mechanism to temperature changes during charging can be tested. Such tests can be used in the following scenarios:

[0146] Safety tests for public charging stations: Test whether the vehicle can maintain charging safety under a forged temperature data attack in a public charging station.

[0147] Safety of fleet charging management: Ensure that during the large-scale fleet charging management process, the vehicle will not have potential safety hazards during charging due to forged temperature data.

[0148] Safety of home charging stations: In the home charging scenario, ensure that the vehicle can automatically take appropriate protective measures when the temperature data is abnormal.

[0149] Regarding forging charging status data and deceiving the abnormal status data processing ability of the charging port, it means that during the charging process, forged charger status data is periodically sent to deceive the protocol stack and test the protocol stack's abnormal handling ability, which may deceive the vehicle to stop charging.

[0150] During the charging process of electric vehicles, the charging pile and the vehicle continuously exchange status data through the protocol stack. These status data include key information such as the working status, connection status, current, and voltage of the charger.

[0151] The charging status data is used to monitor the entire charging process and ensure that the vehicle and the charging pile can make correct responses in case of anomalies. For example, if an abnormal connection of the charging port is detected, the vehicle or the charging pile will trigger a protection mechanism to pause or stop charging.

[0152] The test objective is to periodically send false abnormal status information to the vehicle by forging charging status data (such as charger status, connection status, etc.) to test the protocol stack's handling ability when receiving abnormal status data.

[0153] Focus on evaluating whether the protocol stack can correctly identify forged charging status data, and whether the vehicle will react unreasonably based on incorrect status information (such as stopping charging erroneously).

[0154] Use a charging data collector to capture charging status data packets during the charging process, capturing the charging status data packets exchanged between the vehicle and the charging pile. Pay particular attention to information such as the charger status, connection status, current, and voltage.

[0155] Common charging statuses include:

[0156] Charger status: Indicates whether the charger is in a working state, standby state, error state, etc.

[0157] Connection status: Indicates whether the physical connection status between the vehicle and the charging pile is normal.

[0158] Current / voltage data: Monitor the current and voltage values transmitted during the charging process to ensure they are within a safe range.

[0159] By analyzing the captured packets, understand the structure of the charging status data, especially the fields related to the charger working status, connection status, etc.:

[0160] Working status field: Indicates whether the charger is running, whether charging is in progress, or whether it is in an abnormal state.

[0161] Connection status field: Used to determine whether the vehicle is correctly connected to the charging pile and the stability of the connection.

[0162] Current / voltage monitoring field: Used to report the current charging current and voltage and detect whether there are abnormal changes.

[0163] When forging charger status data, it includes forging abnormal states: constructing forged charger abnormal state packets. For example, forging that the charging pile is in an overheated or faulty state to deceive the vehicle into thinking that the charging pile cannot continue to provide stable charging services.

[0164] Forging standby state: Simulate the charger suddenly entering the standby state, send a status packet to the vehicle, forge the situation where the charging pile stops power supply, and test whether the vehicle will stop charging based on this.

[0165] Forging connection disconnection: During the charging process, forge the connection status as "disconnected", send a packet to the vehicle, and test whether the vehicle will think that the connection between the charging port and the charging pile is interrupted and immediately stop charging.

[0166] Forging unstable connection: Forge an unstable connection state, simulate a poor physical connection of the charging port, send intermittent forged "connection disconnection" and "reconnection" states to the vehicle, and test the vehicle's response.

[0167] Forging excessive current / voltage data: Construct messages with forged current or voltage exceeding the safe range, simulate excessive current or voltage output by the charging pile, and test whether the vehicle will stop charging or trigger the protection mechanism based on this information.

[0168] Forging low current / voltage data: Simulate insufficient output power of the charging pile, send forged low current or voltage messages, and test the vehicle's handling ability in a low-power state.

[0169] During the charging process, use a charging data collector to construct forged charging status data and periodically send this data to the vehicle. By continuously sending forged abnormal status data, observe the vehicle's handling ability for these abnormal signals. The forged data can include overheating of the charger, disconnection, or abnormal working status of the charging pile, etc.

[0170] Observe whether the vehicle will exhibit the following behaviors after receiving the forged charging status data:

[0171] Stop charging: Will the vehicle wrongly stop charging due to the forged status data?

[0172] Power adjustment: Will the vehicle automatically adjust the charging power due to the forged current / voltage abnormal data?

[0173] Alarm trigger: Will the vehicle trigger a wrong alarm system or safety mechanism based on the forged abnormal status data?

[0174] Log record: Will error logs related to the forged abnormal status be recorded in the vehicle's internal system?

[0175] Does the vehicle and the charging pile have a verification mechanism for charging status data? For example, when the forged charging status is inconsistent with the status actually perceived by the vehicle, can the protocol stack detect and ignore the forged message?

[0176] When the protocol stack receives the forged abnormal charging status data, can it handle it reasonably and prevent the charging process from being affected? For example, will the protocol stack perform multiple verifications before the wrong status data triggers the charging stop?

[0177] When the protocol stack detects the forged charging abnormal status, will it trigger a safety mechanism to prevent the forged data from damaging the charging process? For example, will the protocol stack confirm whether the charging status is abnormal through repeated verification or feedback mechanism and take appropriate countermeasures?

[0178] Regarding defense measures and security enhancement suggestions, the charging status data between the vehicle and the charging pile should use encrypted transmission (such as TLS or SSL) and message integrity verification (such as HMAC) to prevent forgery and tampering. Through the encryption mechanism, ensure that the charging status data cannot be tampered with by attackers.

[0179] The protocol stack should be based on a multi-state data verification mechanism to ensure the accuracy of the charging status information. For example, combine the status data of the vehicle's own sensors with the feedback information of the charging pile to verify the authenticity of the status message.

[0180] When the protocol stack detects abnormal charging status data, it should trigger a feedback mechanism to request the charging pile to reconfirm the status data. In this way, the vehicle can prevent making wrong decisions based on single abnormal status data.

[0181] Regarding application scenarios, including:

[0182] Security testing of public charging stations: Ensure that in public charging stations, the vehicle will not interrupt charging or trigger a wrong protection mechanism due to forged charging status data.

[0183] Fault handling in fleet charging management: For large-scale fleet charging management, ensure that the vehicle can correctly handle forged charging status data and will not wrongly stop charging under forged abnormal conditions.

[0184] Security of home charging stations: During home charging, ensure that the vehicle can detect forged status data and make a correct response to avoid unnecessary charging interruptions.

[0185] Furthermore, the operation of forging a charging interruption for the vehicle to be tested, sending a forged charging-abort message, and obtaining the charging-abort response result of the vehicle to be tested further includes:

[0186] During the charging process, the tester forges a message to stop charging and sends a false stop-charging signal to the vehicle to be tested;

[0187] Collect the reaction of the vehicle to be tested after receiving the false stop-charging signal, whether it immediately stops charging or whether it recognizes the forged signal and continues charging.

[0188] Furthermore, sending an invalid message to the vehicle to be tested for DDoS testing and time synchronization testing, and obtaining the charging system stability and time verification ability of the vehicle to be tested further includes:

[0189] Before and during charging, the tester sends multiple invalid messages to the vehicle and the charging pile to test the anti-DDoS attack ability;

[0190] Collect the performance of the charging system of the vehicle to be tested when facing high-traffic invalid messages, including response time, charging interruption situation, and fault alarms;

[0191] During the charging parameter configuration stage, the vehicle to be tested completes parameter configuration and periodically sends time data to the charging pile. The tester forges the time data in compressed and uncompressed formats to deceive the vehicle to be tested into performing time configuration;

[0192] Collect whether the vehicle to be tested makes an error after receiving the forged time data, including the accuracy of the charging log record.

[0193] Among them, in this embodiment, the DDOS test is to send a large number of messages within a short time before and during charging to test the vehicle's ability to resist DDOS.

[0194] A DDoS (Distributed Denial of Service) attack is to send a large number of invalid requests to the target system to consume its resources and make it unable to respond to legitimate requests normally. In the intelligent charging scenario, a DDoS attack may affect the normal communication between the charging pile and the vehicle, resulting in the charging process being interrupted or delayed. Before and during charging, a DDoS attack on the vehicle or the charging pile may cause the system to overload, affecting the safety and reliability of charging.

[0195] The test objective is to send a large number of invalid messages within a short time to test the resistance of the vehicle and the charging pile to DDoS attacks. Observe the performance of the system under DDoS attacks, including response time, charging interruption situation, and any possible security alarms.

[0196] During the charging process, use a charging data collector to capture normal communication messages. These messages usually include information such as charging requests, charging status updates, and charging parameter settings. Analyze the format of the normal communication messages to determine important fields such as frame ID, data length, and DID.

[0197] Identify the key communication messages between the vehicle and the charging pile during the charging process so that when conducting a DDoS test, a large number of these specific types of messages can be sent.

[0198] Forged a large number of invalid charging request messages. These messages can be: messages with incorrect formats: deliberately using formats that do not conform to the protocol to cause system errors or exceptions; false charging requests: forging charging requests with content including parameters that exceed the capacity of the battery or the charging pile.

[0199] During the attack stage, generate a large number of forged messages and ensure that they are sent quickly within a short time. This can be achieved through automated tools or scripts to achieve high-concurrency sending of a large number of messages within a short time.

[0200] Before and during charging, launch a DDoS attack to send a large number of invalid messages to the vehicle and charging pile;

[0201] Record the number of messages sent, their frequency, and duration to analyze the intensity of the attack.

[0202] Observe the reactions of vehicles and charging stations when facing DDoS attacks:

[0203] Response time: Whether the time it takes for the system to respond to normal requests increases significantly and whether the charging process is affected.

[0204] Charging interruption: Whether there is a charging interruption or the charging pile cannot communicate normally with the vehicle.

[0205] Error handling: Whether the system can promptly identify and filter invalid DDoS traffic and maintain normal charging status.

[0206] Afterwards, the system's anti-DDoS capabilities are verified, including traffic monitoring and control: whether the vehicles and charging piles have effective traffic monitoring and control mechanisms, and whether they can automatically identify and block abnormal traffic under high traffic conditions; abnormal alarm system: when a DDoS attack occurs, whether it can trigger an alarm and record detailed attack logs for subsequent analysis.

[0207] In the event of a DDoS attack, can the vehicle and charging pile ensure the safety of the charging process, not be affected by the attack, and continue charging normally?

[0208] Whether the battery's charging state, charging efficiency and safety parameters can be maintained.

[0209] Introduce traffic filtering and restriction mechanisms to monitor the communication between charging piles and vehicles in real time. Ensure that normal communication is not affected by identifying and filtering abnormal traffic. Utilize specialized DDoS protection services to provide higher traffic processing capabilities and multi-level protection strategies to resist large-scale DDoS attacks.

[0210] Conduct security audits and DDoS tests regularly to evaluate the system's ability to resist attacks and to promptly identify and fix potential security vulnerabilities.

[0211] For application scenarios, including:

[0212] Public Charging Station Security Assessment: Evaluate the response capabilities of public charging stations when they are attacked by DDoS to ensure that they can effectively protect users' charging experience.

[0213] The stress resistance of fleet charging management: Conduct DDoS tests on the centralized charging scenarios of the fleet to ensure that all vehicles can operate normally during charging and are not affected by attacks.

[0214] Safety of Home Charging Devices: Test the stability of home charging piles under high traffic conditions to ensure the charging safety of home electric vehicles.

[0215] During the charging parameter configuration phase, after the vehicle completes parameter configuration, send forged time data (compressed and uncompressed) to the vehicle periodically to deceive the vehicle's time data configuration.

[0216] Before the vehicle and the charging pile start charging, in addition to the handshake protocol, there is also a parameter configuration phase. This phase involves the configuration of charging-related parameters such as current, voltage, and power, and sometimes includes system time synchronization.

[0217] The vehicle and the charging pile need to synchronize the system time to use a consistent time reference for communication, error logging, and future charging operations. This is crucial for functions such as recording charging events and performing task scheduling.

[0218] By forging time synchronization data (such as sending incorrect timestamps or incorrect time formats), the vehicle's reaction when receiving forged time data can be tested to verify whether it has a time synchronization verification mechanism.

[0219] The forged data can include compressed time data (such as shortened timestamps) or uncompressed time data (such as using incorrect formats) to test the vehicle's processing ability for different time data formats.

[0220] During the charging parameter configuration phase, messages containing time information are exchanged between the vehicle and the charging pile. Use a charging data collector to capture and record these messages, focusing on the fields containing time data. These messages usually include timestamps, synchronization identifiers, or other time parameters in periodic communication to keep the system time consistent for both parties.

[0221] By analyzing normal time synchronization messages, determine the format of the time data, including:

[0222] Timestamp: Usually a time identifier in seconds or milliseconds, used to record the specific moments of the start, end, or interruption of charging.

[0223] Compressed time data: Sometimes the protocol uses compressed timestamps (such as simplified time units) to reduce the data transmission burden.

[0224] Uncompressed time data: Use standard format timestamps, such as UTC timestamps or local timestamps.

[0225] After that, construct compressed and uncompressed forged time data. The compressed time data deception involves forging a compressed time data packet. For example, shortening the current time to an incorrect value (such as deleting the millisecond part in the timestamp), so that the vehicle receives an incomplete time synchronization message. This type of forged data may cause inaccurate time records or time jumps in the vehicle, especially when recording charging logs.

[0226] The uncompressed time data deception involves constructing an uncompressed time data packet containing incorrect time information. For example, using a future timestamp or an invalid time format (such as a value outside the date range). This type of forgery may cause the vehicle's system time to be inaccurate, affecting log recording and event triggering during the charging process.

[0227] After the vehicle completes parameter configuration and enters the charging preparation stage, use a charging data collector to send forged time synchronization data to the vehicle. Continuous time synchronization attacks can be simulated by periodically sending compressed or uncompressed time data. Use the same message format and communication protocol to make the vehicle think that these forged time data come from the charging pile.

[0228] Observe the vehicle's behavior after receiving the forged time data, especially its reaction in terms of time synchronization and charging log recording.

[0229] For successful deception cases: If the vehicle accepts the forged time data, it may lead to inconsistent times in the charging log and even affect the scheduling of future charging events. For verification failure cases: If the vehicle has a time synchronization verification mechanism, it may reject these forged data and report a time synchronization error.

[0230] To verify the vehicle's time synchronization ability, adopt time synchronization protection mechanisms, including timestamp verification: Whether the vehicle can verify the validity of the received timestamp. For example, whether it will check if the timestamp is within a reasonable range or if it matches the local time of the charging pile. Time format verification: Whether the vehicle will verify the format of the time data to ensure that the received time data conforms to the expected compressed or uncompressed format. The vehicle's processing logic is that if it receives invalid time data, will the vehicle continue to use the time of the last synchronization or will it roll back to the default time? Will it record the error of time synchronization failure in the log or prompt the user or maintenance personnel through an alarm system?

[0231] To prevent time synchronization data from being forged or tampered with, the time data should be transmitted using encryption technologies (such as TLS / SSL). At the same time, the message should include an integrity check (such as HMAC) to ensure that the data has not been tampered with.

[0232] When receiving time synchronization data, the vehicle should perform strict verification, including:

[0233] Timestamp range check: Ensure that the received timestamp is within a reasonable range (e.g., not too far ahead or behind the current time).

[0234] Format verification: The vehicle should support and verify different time formats to ensure that the received time data complies with the protocol requirements.

[0235] If abnormal time data is detected, the vehicle should have a recovery mechanism, such as continuing to use the previous valid time or prompting the user to manually adjust the system time.

[0236] For application scenarios, including:

[0237] Time management in public charging stations: Ensure that the time synchronization mechanism in public charging stations is not vulnerable to attacks and avoid incorrect time records.

[0238] Fleet management and scheduling: For large-scale fleets, time synchronization is crucial to ensure that the charging logs and scheduling of the fleet are consistent with the central system.

[0239] Log management in home charging stations: In a home charging system, ensure the consistency of time records between the vehicle and the charging pile to avoid deviations in future data analysis.

[0240] Furthermore, evaluating the comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data based on the demand response result, charging feedback information, charging interruption response result, charging system stability, and time verification ability, and outputting a security assessment report, further includes:

[0241] CAN configuration information, at least including: serial number, channel, arbitration bit rate, source address, destination address, padding;

[0242] Startup test running parameters, at least including: connection timeout, send timeout, receive timeout, pre-test case delay, maximum send rate of test cases, message interval of test cases, number of retries when initialization fails, action after all initializations fail;

[0243] Task stop conditions, at least including: task running time, number of test cases, number of abnormal cases;

[0244] Interoperability test running parameters, at least including: connection timeout, send timeout, receive timeout, pre-interoperability test delay, message interval of interoperability test, number of retries when connection fails;

[0245] Packet capture settings, at least including: whether to enable packet capture, IP address, port;

[0246] Periodic message configuration, including at least: whether to send periodic messages, CAN ID, EFF ID, DATA, period, whether to enable packet capture, IP address, port;

[0247] Receive filter rules, including at least: whether to set receive filter rules, CAN ID, MASK, EFF ID;

[0248] Probe case configuration, including at least: whether to enable the monitor, probe case pre-delay, probe case retry times, probe case timeout, probe case frequency, probe case interval, probe case consecutive failure times, probe case consecutive failure time;

[0249] External command configuration, including at least: whether to enable the monitor, execute before task start, execute before each case start, execute after each case end, execute when test case fails, execute after task end, execute when probing target status;

[0250] Engine mode, including at least mutation mode, field combination mutation mode, field combination mutation quantity, frame combination mode.

[0251] Among them, in this embodiment, for the above relevant parameters, refer to Table 1-10.

[0252] Table 1 CAN Configuration Information Table

[0253]

[0254] Table 2 Startup Test Run Parameter Table

[0255]

[0256] Table 3 Task Stop Condition Table

[0257]

[0258] Table 4 Interoperability Test Run Parameter Table

[0259]

[0260] Table 5 Packet Capture Setting Table

[0261]

[0262] Table 6 Periodic Message Configuration Table

[0263]

[0264] Table 7 Receive Filter Rule Table

[0265]

[0266] Table 8 Detection Test Case Configuration Table

[0267]

[0268] Table 9 External Command Configuration Table

[0269]

[0270] Table 10 Engine Configuration Table

[0271]

[0272] Refer to Tables 11 - 12, run the test cases for relevant parameters to obtain corresponding test results.

[0273] Table 11 Test Result Table

[0274]

[0275] Table 12 Test Case Table

[0276]

[0277] Furthermore, the method further includes:

[0278] When the vehicle to be tested is starting to charge, forge in - vehicle data, forge a data message for stopping charging, and detect whether the vehicle to be tested can recognize the forged data to deceive the vehicle to be tested to stop charging;

[0279] When the vehicle to be tested is stopped charging, deceive the vehicle to be tested to start charging.

[0280] Furthermore, when the vehicle to be tested is stopped charging and is deceived to start charging, the method further includes:

[0281] The charging data collector is respectively connected to the charging port and the charging gun of the vehicle to be tested, scans or swipes the card to start charging, stops charging after about a preset duration, constructs test data, and deceives the vehicle to start charging;

[0282] Obtain the message difference of the vehicle to be tested at the start and stop of charging, and based on the message difference, use the charging data collector to construct a simulated message to simulate the charging pile to resend a start - charging command to the vehicle;

[0283] Observe whether the vehicle responds to the forged start - charging message and whether it re - enters the charging state;

[0284] If the vehicle to be tested restarts charging, it indicates that the system does not have a sufficient security verification mechanism and accepts the forged start signal;

[0285] If the vehicle to be tested ignores the forged start charging message, it indicates that the vehicle has a security verification mechanism to prevent unauthorized restart of charging.

[0286] The security verification mechanism of the vehicle to be tested for forged messages includes using message freshness verification, handshake verification, timestamp verification or other security measures to prevent unauthorized charging start.

[0287] If the vehicle to be tested verifies the message freshness, it rejects outdated or duplicate start commands.

[0288] During handshake verification, a re - handshake is required to confirm the security status. If the forged message lacks key handshake information, the vehicle refuses to recharge.

[0289] Among them, in this embodiment, in the case of stopping charging, the spoofed vehicle is made to start charging, that is, the charging data collector is respectively connected to the vehicle charging port and the charging gun, and charging is started by scanning or swiping the card. After about two minutes, charging is stopped. At this time, test data is constructed to deceive the vehicle into stopping charging.

[0290] The vehicle and the charging pile communicate through standard charging protocols (such as CHAdeMO, CCS or GB / T, etc.). When starting charging, the charging pile shakes hands with the vehicle and exchanges power transmission protocols. When the vehicle or the charging pile sends a stop charging command, the charging process terminates, the charging gun stops power supply, but the communication channel still exists.

[0291] Use a charging data collector to capture and record all communication data within two minutes after the start of charging, especially the messages at the start and stop of charging. Important information includes:

[0292] Frame ID: Used to identify the data stream of each message.

[0293] Message content: Such as handshake information, charging status, error code, etc.

[0294] Current and voltage information: Messages used to transmit power - related information.

[0295] When charging stops, a series of stop - charging signals are exchanged between the vehicle and the charging pile. The collector should record these signals, analyze the messages and specific data fields at the time of stopping charging, especially the stop - charging command or event identifier.

[0296] Analyze the differences in messages at the start and stop of charging, focusing on:

[0297] Handshake protocol: Confirm the specific steps for starting charging.

[0298] Start and Stop Conditions: Analyze whether there are specific identifiers in the stop charging message, and whether there are start commands or recharging conditions that can be forged.

[0299] DID and Frame ID: Determine the frame IDs and data identifiers (DIDs) related to starting and stopping charging, which are crucial for subsequent simulated data.

[0300] Based on the previously analyzed handshake protocol and start process, use the data collector to construct a simulated message to simulate the charging pile sending a start charging command to the vehicle again.

[0301] Frame ID: Use the frame ID related to starting charging.

[0302] Content of the Simulated Message: Construct a message similar to the actual start charging, imitating the start signal and requests for current and voltage in the handshake protocol.

[0303] Power Parameters: The values of current and voltage can be appropriately modified or forged to be consistent with those during start charging.

[0304] After charging stops, use the data collector to send the constructed forged message to the vehicle to simulate the charging pile reinitiating a start charging request. By using the same frame ID and DID, make the vehicle think that the charging pile starts the handshake again.

[0305] Observe whether the vehicle responds to the forged start charging message and whether it re-enters the charging state.

[0306] If the vehicle restarts charging, it indicates that the system does not have a sufficient verification mechanism and accepts the forged start signal.

[0307] If the vehicle ignores the forged message, it indicates that the vehicle has a certain security verification mechanism to prevent unauthorized restart of charging.

[0308] Test whether the vehicle verifies the forged message. Some vehicles or charging piles may use message freshness verification, timestamp verification, or other security measures to prevent unauthorized charging starts.

[0309] Message Freshness: If the vehicle verifies message freshness, it may reject outdated or repeated start commands.

[0310] Handshake Verification: Some systems may require re-handshaking to confirm the security status. If the forged message lacks key handshake information, the vehicle may reject recharging.

[0311] Handshake Encryption: To prevent similar attacks, the handshake protocol between the vehicle and the charging pile should use an encryption mechanism to ensure that the communication content cannot be easily forged or tampered with.

[0312] Authentication mechanism: A two-way authentication mechanism should be introduced for the communication between the charging pile and the vehicle to prevent forged charging requests from passing through.

[0313] Message integrity check: Add an integrity check (such as CRC check or HMAC authentication) to each charging communication to ensure that the received message has not been tampered with.

[0314] For specific applications in implementation, including:

[0315] Security of public charging stations: Prevent malicious attackers in public charging stations from forging start signals to induce vehicles to charge illegally.

[0316] Protection of home charging piles: Test the security of home charging devices after charging stops to prevent the communication between the charging pile and the vehicle from being tampered with, resulting in unnecessary recharging.

[0317] Enterprise fleet management system: In the management of a large-scale electric vehicle fleet, prevent unnecessary charging consumption and waste of system resources, and ensure the security of the charging process.

[0318] Furthermore, the method further includes:

[0319] During the charging handshake phase, forge protocol stack version data to test the abnormal handling ability of the vehicle protocol stack;

[0320] Use the charging data collector to capture all handshake messages exchanged between the vehicle to be tested and the charging pile during the charging handshake phase. The version number included in the handshake message is used to ensure the communication compatibility between the charging pile and the vehicle to be tested;

[0321] Construct forged protocol stack version data by forging the version number or modifying the function bit. During the handshake phase, insert the forged protocol stack version data through the charging data collector to simulate inconsistent protocol versions or incorrect version information sent by the charging pile;

[0322] Obtain whether the vehicle to be tested will start charging normally or report an error after receiving the forged protocol stack version data;

[0323] If the vehicle to be tested has a version verification mechanism, reject charging and report an error of protocol version mismatch;

[0324] If the vehicle to be tested does not have an effective verification mechanism, start charging but exhibit abnormal behavior or stop charging.

[0325] Among them, in this embodiment, spoofing the vehicle protocol version is to forge protocol stack version data during the charging handshake phase to test the abnormal handling ability of the vehicle protocol stack.

[0326] Before a vehicle starts charging with a charging pile, the two parties will perform a handshake through a charging protocol (such as CHAdeMO, CCS, GB / T, etc.). This process includes version matching, function confirmation, and negotiation of parameters such as voltage and current. The protocol stack version information is exchanged during the handshake phase to ensure compatibility of the charging protocols used by both parties. If the protocol versions of the vehicle or the charging pile are incompatible, it may cause the charging to not start properly or be interrupted.

[0327] By forging the version data of the protocol stack during the handshake phase, the vehicle's ability to handle protocol stack anomalies can be tested. This kind of forged data attack can evaluate whether the vehicle will perform appropriate error handling when the charging protocol versions do not match.

[0328] Use a charging data collector to capture all communication messages exchanged between the vehicle and the charging pile during the charging handshake phase. Pay particular attention to the message fields containing protocol stack version information, such as version numbers, function bit identifiers, etc.

[0329] Analyze the specific structure and content of the protocol stack version data to ensure that the key data fields used to identify the version can be recognized.

[0330] The version number contained in the handshake message is used to ensure communication compatibility between the charging pile and the vehicle. This may include:

[0331] Protocol stack major version number: Identifies the major version of the charging protocol (such as 1.0, 2.0, etc.).

[0332] Protocol stack minor version number: Used to distinguish different secondary versions under the same major version.

[0333] Feature Bits: Indicate the set of supported functions, such as support for specific voltages or currents, etc.

[0334] During the handshake phase, the protocol stack version data is usually part of the handshake message. By analyzing the normal handshake data, determine the frame ID, data length, DID (data identifier), etc. of the protocol stack version.

[0335] The version information usually contains multiple bytes, and each byte identifies the major version number, minor version number, or specific function support information.

[0336] Use the collector to construct forged version data. The version information can be forged in the following ways:

[0337] Too low version number: Forge a version number lower than the vehicle's protocol stack version to test how the vehicle handles an unsupported old version.

[0338] Too high version number: Forge a version number higher than the version supported by the vehicle to test the vehicle's reaction when it cannot support this version.

[0339] Randomized version number: Input a completely invalid or random version number to test the fault tolerance mechanism of the vehicle.

[0340] In addition to forging the version number, the functions supported by the protocol stack can also be forged by modifying the function bits. For example, forge the support for some incompatible voltage, current, or security authentication functions to test whether the vehicle can correctly handle these incorrect function declarations.

[0341] During the handshake phase, insert forged protocol stack version data through the charging data collector to simulate inconsistent or incorrect version information of the protocol version sent by the charging pile. Ensure that the forged version number is incompatible with the vehicle to observe how the vehicle handles this situation.

[0342] Observe whether the vehicle can start charging normally or report an error after receiving the forged protocol stack version data.

[0343] If the vehicle has a version verification mechanism, it may reject charging and report an error of protocol version mismatch.

[0344] If the vehicle does not have an effective verification mechanism, it may start charging but exhibit abnormal behavior or stop charging.

[0345] Verify the vehicle's exception handling ability using an exception detection mechanism, including:

[0346] Version verification mechanism: Whether the vehicle can detect version mismatch or abnormal function bits during the handshake phase and interrupt charging in a timely manner.

[0347] Error reporting: Whether the vehicle can correctly record and report protocol stack exceptions, including error codes or detailed log records.

[0348] Downgrade mechanism: Some vehicles may have a protocol version downgrade mechanism (such as falling back to an old supported version), test whether the vehicle has such a function.

[0349] The vehicle's reaction speed when detecting an anomaly (such as interrupting the handshake protocol, rejecting to start charging) is an important indicator for evaluating its safety and robustness. If the vehicle's response is slow or it fails to handle errors in a timely manner, it may lead to potential safety hazards.

[0350] The vehicle should have a strict protocol stack version verification mechanism to ensure that the handshake process can be interrupted in a timely manner when the protocol stack versions are incompatible, preventing incorrect charging operations.

[0351] The protocol stack version data should use encryption or message integrity check (such as HMAC) to prevent the message from being tampered with. By introducing these security measures, it can effectively prevent forged version numbers or function bits from being injected into the communication stream.

[0352] In the case of protocol version incompatibility, the vehicle should have an automatic downgrading mechanism, that is, fallback to a lower version protocol supported by both parties to ensure that the charging process can still proceed safely.

[0353] For application scenarios, including:

[0354] Safety of public charging stations: Test whether there are incorrect protocol version numbers or function declarations in public charging stations to ensure that the vehicle is not attacked by forged charging pile version numbers.

[0355] Fleet charging management: For large-scale fleets, ensure that the charging system of each vehicle can correctly handle protocol version inconsistencies to avoid charging interruptions or unsafe charging.

[0356] Home charging stations: Test whether the protocol version of home charging piles meets the requirements of the vehicle and ensure the safety of the protocol handshake process.

[0357] Among them, in this embodiment, it also includes: When charging is not started, deceive the vehicle to start charging;

[0358] Refer to Figure 2 , when the charging pile charges the intermediate device normally, the vehicle sends a normal stop signal to the intermediate device. At this time, simulate the continued charging signal and send it to the charging pile by truncating the CAN signal, and then send the continued charging simulation signal to the charging pile.

[0359] After the charging data collector is connected to the vehicle charging port and the charging gun respectively, the charging gun starts low-voltage auxiliary power supply (12V). At this time, charging has not started. The collector receives normal charging messages, analyzes the target frame ID, message length, DID, etc. sent by the message, simulates the message data by the collector and sends it to the same frame ID, and checks whether there is message freshness verification in the vehicle.

[0360] After the connection between the vehicle and the charging pile is established but before high-voltage charging starts, the charging gun will start low-voltage auxiliary power supply (usually 12V). This is to ensure the stability of the initial communication, perform data exchange and handshake protocol confirmation.

[0361] During the auxiliary power supply period, the vehicle and the charging pile will exchange data messages through the CAN bus or other protocols. The charging data collector can capture these messages and analyze their structures and contents.

[0362] Frame ID: The unique identifier of the message, used to distinguish different data streams.

[0363] Message length: Specifies the byte length of the data segment, which may vary according to the frame ID.

[0364] DID (Data Identifier): Data identifier, used to determine the specific function or data field of a message.

[0365] The acquisition device captures this data to understand the communication mode between the vehicle and the charging gun.

[0366] After collecting normal charging messages, the acquisition device needs to analyze the structure of the messages:

[0367] Target frame ID: Used to determine the recipient of the message (e.g., the vehicle's charging control unit).

[0368] Message length: Ensure that the length of the simulated message is the same as the original message to avoid format errors at the protocol layer.

[0369] DID: Depending on the actual situation, the DID may be a specific function call, such as communication confirmation, error status, or charging request, etc.

[0370] Based on the analysis results, the acquisition device constructs a simulated data message with the same structure as the original message and prepares to send it to the vehicle through the same frame ID. The content of this simulated message can be slightly modified or kept the same, with the aim of testing whether the vehicle can recognize forged, outdated, or duplicate messages.

[0371] The acquisition device sends the simulated message to the vehicle using the same frame ID as the original message, which means the vehicle will recognize this simulated message as a legitimate message from the charging gun or charging pile. After sending the simulated message, observe whether the vehicle accepts the message and reacts, or whether it ignores the message.

[0372] Message freshness verification is a security mechanism used to prevent replay attacks or forged messages. By verifying whether the message is the latest generated message, the effectiveness and security of communication can be ensured.

[0373] Timestamp: Many messages will contain a timestamp, and the system verifies the timestamp to ensure the timeliness of the message.

[0374] Counter: Some protocols will attach a counter to the message to track the sending order of the message and ensure that the message has not been repeated or forged.

[0375] Message digest: Some messages may use encryption technologies (such as hashing or MAC) to verify the integrity and source of the message.

[0376] By sending simulated forged messages, check whether the vehicle performs message freshness verification. If the vehicle has a freshness verification mechanism, it will detect that the message is the same as or outdated compared to the previous message and discard it.

[0377] If the vehicle ignores the simulated message, it means that the vehicle has performed freshness verification.

[0378] If the vehicle accepts the simulated message and responds, it indicates that the vehicle may not have performed freshness verification, or there are loopholes in the verification mechanism.

[0379] For specific applications in implementation, including:

[0380] Public charging pile environment: Test whether there is a mechanism to prevent message replay or forgery when the public charging pile communicates with the vehicle to improve charging safety.

[0381] Home charging scenario: Ensure that when the vehicle communicates with the home charging station, it can correctly verify the freshness of the message to avoid malicious attacks.

[0382] Electric vehicle fleet management: When the vehicle is charging, by testing the security of the message, ensure that there are no communication loopholes during the charging process of the entire fleet to ensure the safe charging of electric vehicles.

[0383] Among them, this embodiment also includes, in the case of starting charging, deceiving the vehicle to stop charging, that is, the charging data collector is respectively connected to the vehicle charging port and the charging gun, scans or swipes the card to start charging, constructs CHM test data, and deceives the vehicle to stop charging.

[0384] First, the CHM test data deceives the vehicle to stop charging. Among them, CHM (Charging Handshake Message) is a part of the charging protocol, which is responsible for performing handshakes at the beginning of charging to ensure the connection and communication between the vehicle and the charging pile are safe and effective. If the handshake fails, the charging cannot proceed or will be interrupted;

[0385] The charging data collector connects to the vehicle's charging port and the charging gun, and captures and records all data of the communication between the two parties in real time, especially the CHM data in the handshake protocol stage;

[0386] Analyze the CHM data to identify the information exchanged between the two parties during the handshake, such as voltage and current parameters, error codes, and communication status.

[0387] During the charging process, forge a wrong CHM test data packet. For example, the forged data packet can show communication failure, parameter mismatch, or abnormal voltage situation.

[0388] Common attack methods include: modifying the error code transmitted in the communication, sending a false stop charging instruction, or constructing forged power transmission problem information.

[0389] Use the charging data collector to insert the forged CHM test data into the real charging communication stream.

[0390] This can be achieved by interrupting the real data exchange and replacing or inserting forged data packets. The goal is to make the vehicle detect communication anomalies or parameter errors, trigger its protection mechanism, and automatically stop charging.

[0391] The forged CHM data packet will cause the vehicle to think that there is a problem during the charging process, such as communication failure or security threat, thus automatically stopping the charging process.

[0392] Once the vehicle stops charging, the system may require re - handshaking or detect anomalies and record error messages.

[0393] During security defense, authentication and encryption are carried out: Ensure that the communication between the charging pile and the vehicle is authenticated and encrypted to prevent man - in - the - middle attacks or data tampering. Encrypt CHM messages through a secure handshake protocol (such as TLS / SSL) to prevent the insertion of forged messages; Data integrity check: Perform integrity verification on data packets during the charging process to ensure that all communication data has not been tampered with; Anomaly detection: The vehicle and the charging pile can be designed with an anomaly detection mechanism. When suspicious or invalid handshake messages are detected, an alarm is issued or detailed logs are recorded for subsequent analysis.

[0394] For the specific applications of the implementation scenarios, including:

[0395] Public charging stations: Through the data collector, an attack is carried out when the vehicle is charging, inducing the vehicle to stop charging, which brings inconvenience to users.

[0396] Communication interruption between the vehicle and the private charging pile: An attack is carried out on the home or enterprise charging pile, resulting in the inability to complete the charging task. Fleet charging management system: In the fleet charging system, an attack is carried out on the communication between vehicles, causing charging interruption, thus affecting the normal use and operation efficiency of the vehicles.

[0397] According to the second embodiment of the present invention, the present invention claims a security test system for vehicle charging interface information, including:

[0398] One or more processors;

[0399] A memory, on which one or more programs are stored. When the one or more programs are executed by the one or more processors, the one or more processors implement the security test method for vehicle charging interface information described above.

[0400] In several embodiments provided by the present invention, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections between each other can be indirect couplings or communication connections through some interfaces, devices, or units, and can be in electrical, mechanical, or other forms.

[0401] In addition, each functional unit in various embodiments of the present invention can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units. The above is only the implementation manner of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or equivalent process transformation made using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present invention.

[0402] The specific implementation manners of the invention have been described in detail above, but they are only examples, and the invention is not limited to the specific implementation manners described above. For those skilled in the art, any equivalent modification or substitution to the invention is also within the scope of the invention. Therefore, equal transformation, modification, improvement, etc. made without departing from the spirit and principle of the invention should be covered by the scope of the invention.

Claims

1. A safety testing method for vehicle charging interface information, characterized in that: include: Sending a normal charging demand message and a forged charging demand message to the vehicle to be tested, and obtaining a demand response result of the vehicle to be tested; Charging the vehicle to be tested, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle to be tested, and collecting charging feedback information of the vehicle to be tested; Performing a charging interruption forging operation on the vehicle to be tested, sending a forged charging suspension message, and obtaining a charging suspension response result of the vehicle to be tested; Sending invalid messages to the vehicle to be tested to perform DDoS testing and time synchronization testing to obtain the charging system stability and time verification capability of the vehicle to be tested; According to the demand response results, charging feedback information, charging suspension response results, charging system stability and time verification capability, the comprehensive performance of the tested vehicle and charging pile under different attacks and forged data conditions is evaluated, and a security assessment report is output; When the vehicle to be tested starts charging, the vehicle data is forged, a data message for stopping charging is forged, and it is detected whether the vehicle to be tested can recognize that the forged data is used to deceive the vehicle to be tested to stop charging; When the vehicle to be tested stops charging, deceiving the vehicle to be tested to start charging; When the vehicle to be tested stops charging, deceiving the vehicle to be tested to start charging, the method further includes: The charging data collector is connected to the charging port and charging gun of the vehicle to be tested respectively, scans or swipes a card to start charging, stops charging after a preset time, and constructs test data to deceive the vehicle to stop charging; Obtain the message difference of the vehicle to be tested when charging starts and stops, and based on the message difference, use the charging data acquisition instrument to construct a simulation message to simulate the charging pile to resend a start charging command to the vehicle; Observe whether the vehicle responds to the forged charging start message and re-enters the charging state; If the vehicle to be tested restarts charging, it means that the system does not have sufficient safety verification mechanism and accepts a forged start signal; If the vehicle to be tested ignores the forged charging start message, it indicates that the vehicle has a safety verification mechanism to prevent unauthorized restart charging; The safety verification mechanism of whether the vehicle to be tested performs forgery of the message includes using message freshness verification, handshake verification, and timestamp verification to prevent unauthorized charging start; If the vehicle under test verifies the message freshness, an outdated or repeated start command is rejected; During handshake verification, a re-handshake is required to confirm the safety status. If the forged message lacks key handshake information, the vehicle will refuse to recharge; During handshake verification, a re-handshake is required to confirm the safety status. If the forged message lacks key handshake information, the vehicle will refuse to recharge; The vehicle and the charging station communicate via a standard charging protocol; When starting charging, the charging pile shakes hands with the vehicle and exchanges power transmission protocols; When the vehicle or charging pile sends a stop charging command, the charging process is terminated and the charging gun stops supplying power, but the communication channel still exists.

2. A safety testing method for vehicle charging interface information according to claim 1, characterized in that: The sending of a normal charging demand message and a forged charging demand message to the vehicle to be tested, and obtaining a demand response result of the vehicle to be tested, further includes: Before charging begins, the vehicle to be tested sends charging demand and charging mode data to the charging pile, first capturing normal charging demand messages to determine the vehicle's response mechanism to changes in charging demand; After capturing normal charging demand data, the tester constructs a forged charging demand message, sends it to the charging pile, and observes the vehicle's response to the forged charging demand message.

3. A safety testing method for vehicle charging interface information according to claim 1, characterized in that: The step of charging the vehicle to be tested, sending normal signal data and forged signal data during the charging process to the charging pile or the vehicle to be tested, and collecting charging feedback information of the vehicle to be tested further includes: After charging starts, the vehicle to be tested periodically sends a normal temperature data message of the battery, and the tester captures and analyzes the normal temperature data message; Sending forged temperature data to determine whether the vehicle to be tested will incorrectly adjust charging parameters or start a cooling system; During the charging process, the tested vehicle exchanges charging status data with the charging pile, and the tester forges the status data of the vehicle's EVCC module and sends false status information to the charging pile to verify the abnormal handling ability of the tested vehicle when facing forged status data; Periodically sending forged charging status data to the vehicle to be tested to obtain a response from the vehicle to be tested.

4. A safety testing method for vehicle charging interface information according to claim 1, characterized in that: The method of performing a charging interruption forging operation on the vehicle to be tested, sending a forged charging suspension message, and obtaining a charging suspension response result of the vehicle to be tested further includes: During the charging process, the tester forges a message to stop charging and sends a false stop charging signal to the vehicle to be tested; The reaction of the vehicle to be tested after receiving the false stop charging signal is collected, whether charging is stopped immediately or whether the false signal is recognized and charging is continued.

5. A safety testing method for vehicle charging interface information according to claim 1, characterized in that: The sending of invalid messages to the vehicle to be tested to perform a DDoS test and a time synchronization test to obtain the charging system stability and time verification capability of the vehicle to be tested also includes: Before and during charging, the tester sent multiple invalid messages to the vehicle and charging pile to test the ability to resist DDoS attacks; Collecting the performance of the charging system of the vehicle to be tested when facing high-flow invalid messages, including response time, charging interruption and fault alarm; In the charging parameter configuration stage, the vehicle to be tested completes parameter configuration and periodically sends time data to the charging pile. The tester forges the time data in compressed and uncompressed formats to deceive the vehicle to be tested to perform time configuration; Collect information on whether the vehicle to be tested has any errors after receiving the forged time data, including the accuracy of the charging log records.

6. A safety testing method for vehicle charging interface information according to claim 1, characterized in that: The comprehensive performance of the vehicle to be tested and the charging pile under different attacks and forged data is evaluated based on the demand response result, charging feedback information, charging suspension response result, charging system stability and time verification capability, and a security assessment report is output, which also includes: CAN configuration information, including at least: serial number, channel, arbitration bit rate, source address, destination address, and padding; Start the test running parameters, including at least: connection timeout, send timeout, receive timeout, test case lead delay, test case maximum send rate, test case message interval, number of retries when initialization fails, and action after all initialization fails; Task stopping conditions, including at least: task running time, number of test cases, and number of abnormal cases; Interoperability test operation parameters, including at least: connection timeout, send timeout, receive timeout, interoperability test lead delay, interoperability test message interval, and number of retries when connection fails; Packet capture settings, including at least: whether to enable packet capture, IP address, and port; Periodic message configuration, including at least: whether to send periodic messages, CAN ID, EFFID, DATA, period, whether to enable packet capture, IP address, and port; Receiving filtering rules, including at least: whether to set receiving filtering rules, CAN ID, MASK, EFF ID; Detection case configuration, including at least: whether to enable the monitor, detection case lead delay, detection case retry times, detection case timeout, detection case frequency, detection case interval, detection case continuous failure times, and detection case continuous failure time; External command configuration, including at least: whether to enable the monitor, execute before the task starts, execute before each use case starts, execute after each use case ends, execute when the test case fails, execute after the task ends, and execute when detecting the target status; The engine mode includes at least a mutation mode, a field combination mutation mode, a field combination mutation quantity, and a frame combination mode.

7. A safety testing method for vehicle charging interface information according to claim 6, characterized in that: Also includes: During the charging handshake phase, the protocol stack version data is forged to verify the vehicle protocol stack's ability to handle exceptions; Using the charging data collector, capturing all handshake messages exchanged between the vehicle to be tested and the charging pile during the charging handshake phase, wherein the version number contained in the handshake message is used to ensure the communication compatibility between the charging pile and the vehicle to be tested; By forging the version number or modifying the function bit to construct forged protocol stack version data, during the handshake phase, the forged protocol stack version data is inserted through the charging data collector to simulate inconsistent or erroneous protocol version information sent by the charging pile; Obtaining whether the vehicle to be tested starts charging normally or reports an error after receiving the forged protocol stack version data; If the vehicle to be tested has a version verification mechanism, charging is refused and an error of protocol version mismatch is reported; If the vehicle to be tested does not have a valid verification mechanism, charging is started but abnormal behavior occurs or charging is stopped.

8. A safety testing system for vehicle charging interface information, characterized in that: include: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a safety testing method for vehicle charging interface information according to any one of claims 1 to 7.

Images