Safety test method for vehicle charging interface information

Abstract

The invention relates to the technical field of vehicle testing, in particular to a safety testing method for vehicle charging interface information, which comprises the following steps: sending normal and forged charging demand messages to a to-be-tested vehicle, and obtaining a demand response result of the to-be-tested vehicle; the vehicle to be tested is charged, normal signal data and forged signal data in the charging process are sent, and charging feedback information of the vehicle to be tested is collected; performing charging interruption forgery operation on the to-be-tested vehicle, sending a forgery charging interruption message, and obtaining a charging interruption response result of the to-be-tested vehicle; sending an invalid message to the to-be-tested vehicle for testing, and obtaining the charging system stability and the time verification capability of the to-be-tested vehicle; and evaluating the comprehensive performance of the to-be-tested vehicle and the charging pile under different attacks and forged data, and outputting a safety evaluation report. According to the method, the comprehensive performance of the vehicle and the charging pile under different attacks and forged data can be effectively evaluated, and a complete safety evaluation report is efficiently formed.

Description

Technical Field

[0001] The present invention relates to the field of vehicle testing technology, and in particular to a safety testing method for vehicle charging interface information. Background Art

[0002] With the popularization of smart cars, the degree of networking of cars continues to improve, and the external interfaces of vehicles (such as charging interfaces, on-board communication interfaces, etc.) are becoming increasingly complex.

[0003] These interfaces not only need to meet charging requirements, but also involve multiple functions such as software updates and data transmission, which poses a challenge to safety supervision. Therefore, it is necessary to carry out compliance testing to form access control protection for charging interfaces and prohibit unauthorized access. Summary of the invention

[0004] To achieve the above object, the present invention provides the following technical solutions: According to a first aspect of the present invention, the present invention claims a safety testing method for vehicle charging interface information, comprising: 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; Based on 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.

[0005] Furthermore, the sending of a normal charging demand message and a forged charging demand message to the vehicle to be tested to obtain a demand response result of the vehicle to be tested also 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.

[0006] Furthermore, the charging of 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 also include: 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 capability 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.

[0007] Furthermore, the 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 also 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.

[0008] Furthermore, 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.

[0009] Furthermore, 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, EFF ID, 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.

[0010] Furthermore, the method further comprises: When the vehicle to be tested starts charging, the vehicle data is forged, a data message for stopping charging is forged, and 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, the vehicle to be tested is deceived into starting charging.

[0011] Furthermore, when the vehicle to be tested stops 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, constructs test data, and deceives the vehicle into starting 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 to be tested verifies the freshness of the message, outdated or repeated start commands are rejected.

[0012] 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.

[0013] Furthermore, the method further comprises: 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.

[0014] 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: one or more processors; 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.

[0015] The beneficial effects of the present invention are: 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; Verify the vehicle's safety mechanisms and exception handling capabilities to ensure it can effectively identify and reject false charging stop requests; By observing whether the vehicle will make errors after receiving forged time data, it can effectively verify whether the vehicle has a strong time synchronization mechanism to ensure that it can make reasonable responses when receiving abnormal time data; Through a series of tests, the results of each link are integrated to evaluate the safety, stability and robustness of the charging system. It can effectively evaluate the comprehensive performance of vehicles and charging piles under different attacks and forged data, and efficiently form a complete security assessment report. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A workflow diagram of a safety testing method for vehicle charging interface information claimed in an embodiment of the present invention Figure 2 A data flow diagram of a security testing method for vehicle charging interface information as claimed in an embodiment of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0018] 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 indicating the number of indicated technical features. Therefore, the features defined as "first", "second" and "third" may explicitly or implicitly include at least one of the features. In the description of the present invention, the meaning of "multiple" is at least two, such as two, three, etc., unless otherwise clearly and 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 position relationship, movement, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication also changes accordingly. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. 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 also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices.

[0019] 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.

[0020] The test software and hardware tools of the embodiment of the present invention meet the following indicators: 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.

[0021] 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℃.

[0022] 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.

[0023] 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.

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

[0025] 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.

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

[0027] 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.

[0028] According to the first embodiment of the present invention, the present invention claims a method for safety testing of vehicle charging interface information, referring to Figure 1 ,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; Based on 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.

[0029] Furthermore, the sending of a normal charging demand message and a forged charging demand message to the vehicle to be tested to obtain a demand response result of the vehicle to be tested also 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.

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

[0031] The charging requirements and modes in the scenario setting and initial conditions are summarized as follows: During the charging process, the vehicle will periodically send charging requirement messages to the charging pile according to the battery requirements, reporting the required charging current, voltage, power and other parameters. The charging mode may include constant voltage charging mode (CV) and constant current charging mode (CC), which determine how to adjust the charging parameters according to the current state of the battery.

[0032] The vehicle's charging requirements typically depend on the battery's current state (e.g., charge level, temperature, state of health), and these requirements change as charging progresses to ensure a safe and efficient charging process.

[0033] The test goal is to send false information to the charging pile by forging the vehicle's charging demand and charging mode data, and test how the vehicle handles abnormal changes in the charging mode after the battery demand changes. Verify whether the vehicle can respond correctly based on the forged charging demand and mode data, especially when the battery demand does not match the actual situation.

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

[0035] When analyzing the charging demand data structure, analyze the captured message structure and determine the key fields in the charging demand data: Voltage Requirement: The current required charging voltage reported by the vehicle.

[0036] Current Demand: The current required for charging as reported by the vehicle.

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

[0038] Charging Mode: An identifier that indicates whether the vehicle is in constant voltage mode or constant current mode.

[0039] When constructing a forged charging demand and mode message, you first need to forge the charging demand message, including current / voltage forgery: construct false charging demand data and send forged overly high or low current / voltage requirements to the charging pile. For example, when the battery is almost fully charged, forge a higher current requirement, or forge a lower voltage requirement when the battery is almost exhausted.

[0040] Power forgery: Construct forged power demand messages and send unreasonable power demands (such as power values ​​that are far higher than the current battery capacity).

[0041] Forged charging mode switching when forging charging mode messages: During the normal charging phase, the vehicle usually switches between different charging modes (for example, from constant current mode to constant voltage mode). Forged messages of this mode switching send false charging mode switching signals to the charging pile to test the vehicle's ability to cope with sudden changes in charging mode. When forging a vehicle in constant voltage mode during constant voltage / constant current mode interference, send a false message of constant current mode, or vice versa, and simulate a mode switch that does not meet actual needs by forging messages.

[0042] Then send fake messages and detect the vehicle response, including periodically sending fake charging demand and mode data: During the charging process, a data logger is used to construct forged charging demand messages and periodically send these forged data to ensure that these forged current, voltage, and power requirements are inconsistent with the actual requirements of the vehicle.

[0043] Fake charging mode data (such as suddenly switching charging modes) and send it regularly to observe the vehicle's reaction to mode changes.

[0044] Detecting the vehicle’s response in abnormal situations: Observe whether the vehicle exhibits abnormal behavior after receiving the forged charging demand and mode data, including: Adjustment Error: Does the vehicle incorrectly adjust battery charging parameters (e.g., current, voltage)? False alarms: Will false fault alarms be generated to indicate abnormal conditions during charging? Safety mechanism activation: Can the vehicle detect falsified data and trigger a protection mechanism to stop charging or switch to a safe mode? Verify the vehicle’s handling capabilities when performing charging demand verification, including whether the vehicle can detect falsified charging demand data? For example, if the battery’s current charging demand is inconsistent with the falsified data, will the vehicle ignore the falsified data and continue to adjust charging parameters based on actual demand? During charging mode verification, when receiving forged charging mode switching data, will the vehicle mistakenly switch the charging mode, or will it detect that the mode switch is inconsistent with the battery status and maintain the current mode? When it comes to safety mechanisms and troubleshooting, does the vehicle have a robust troubleshooting mechanism in place when fake data affects the charging process? If fake charging demands or patterns lead to abnormal behavior, can the vehicle stop charging in a timely manner and record abnormal logs? Propose defense measures and security enhancement suggestions, 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 demand data in the message matches the actual battery demand. The rationality of the charging requirement can be verified through multiple detection mechanisms; Mode switching verification, including switching of charging modes, the vehicle should have a complete state machine verification mechanism. In the mode switching message, the rationality of the mode switching should be verified through multiple aspects such as the current state of the battery and the charging stage to avoid misoperation.

[0045] Abnormal detection and automatic protection, for example, if an unreasonable charging demand or charging mode switching 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 logs to ensure the safety of the charging process.

[0046] Application scenarios include security testing of public charging stations: ensuring that vehicles in public charging stations do not encounter safety hazards due to forged demand messages; security assurance of home charging: testing whether the vehicle can automatically detect and protect the charging process when encountering forged charging demands during home charging; fleet charging management: during the centralized charging process of the fleet, ensure that each vehicle can correctly respond to charging demands and avoid charging anomalies caused by forged data.

[0047] Furthermore, the charging of 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 also include: 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.

[0048] Among them, in this embodiment, the status data of the vehicle EVCC (charging management) module includes data messages that do not have a charging status, such as the current vehicle is not in P gear.

[0049] When testing the power battery temperature, it is necessary to falsify the vehicle battery temperature data during the vehicle charging process.

[0050] For scenario setting and initial conditions, we first need to determine the importance of battery temperature in charging. During the charging process of electric vehicles, the temperature of the power battery is a key factor affecting charging safety and efficiency. Battery temperature that is too high or too low will affect charging performance and may even cause safety issues. Battery temperature data is regularly exchanged between the vehicle and the charging pile so that the charging pile can dynamically adjust charging parameters (such as current, voltage) or trigger the cooling system according to the battery temperature.

[0051] The test goal is to forge the temperature data of the power battery and send false temperature information to the charging pile or vehicle to test the vehicle's response and processing capabilities to the forged temperature data; to observe whether the vehicle will incorrectly adjust the charging parameters based on the forged temperature information, or trigger the wrong safety mechanism under abnormal temperature conditions.

[0052] Then, capture and analyze the messages to capture the battery temperature data messages. 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 the charging data acquisition instrument 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 the single battery, the lowest temperature of the single battery, and the cooling system status.

[0053] When analyzing the temperature message structure, the meaning of each field is determined by analyzing the message structure of the temperature data. The fields include: Average Temperature: The average temperature of the entire battery pack, usually in degrees Celsius.

[0054] Highest / lowest cell temperature: records the temperature of the highest and lowest cells in the battery pack.

[0055] Cooling System Status: An identifier that indicates whether the cooling system is enabled or needs to be enabled.

[0056] Constructing fake battery temperature data includes constructing overly high temperature data: constructing fake temperature data to send false temperature information to the charging station that is much higher than the actual battery temperature. For example, the fake temperature data can be 85°C or higher to simulate battery overheating; Similarly, it is possible to forge low temperature data and send false information to the charging station that is lower than the actual temperature, such as **-20°C**, to simulate an overcooled battery.

[0057] When modifying the cell temperature data, the highest or lowest temperature of the cell is forged. For example, during the charging process, the temperature of a cell is forged to be much higher than that of other cells, triggering an abnormal response from the vehicle or charging station.

[0058] When forging the cooling system status, forged cooling system status data is constructed to simulate the state that the cooling system has been enabled or needs to be enabled, and send wrong information to the vehicle or charging pile, resulting in the incorrect startup or shutdown of the cooling system.

[0059] Then send fake messages and detect the vehicle's response, including sending fake temperature data. During the vehicle charging process, use the data acquisition instrument to send fake temperature data messages to the vehicle and observe the vehicle's response to these fake data. For example, by sending excessively high temperature data, simulate the battery overheating state.

[0060] During the charging process, fake temperature data is sent periodically to simulate a gradual increase or decrease in temperature and test the vehicle's dynamic response to temperature changes.

[0061] Observe the vehicle's behavior after receiving the fake temperature data, especially the adjustment of charging parameters and the reaction of the cooling system: Charging power adjustment: Will the vehicle reduce or increase charging power based on falsified temperature data? Cooling System Response: Will the vehicle erroneously activate or shut down the cooling system based on falsified temperature data? Fault Alarm: Will the vehicle trigger a fault alarm and interrupt charging, especially if falsified temperature data indicates the battery is too hot or too cold? Verify the vehicle’s exception handling capabilities, including data validation mechanisms: Can the vehicle detect falsified temperature data? For example, when falsified temperature data is significantly inconsistent with the actual battery temperature, can the vehicle ignore the false data and continue to make decisions based on the actual temperature? In terms of the system’s response, will the vehicle’s cooling system respond incorrectly if it receives temperature data that is too high or too low? For example, will it incorrectly activate the cooling system when the battery is actually at normal temperature, or fail to activate the cooling system when the battery is overheated? Regarding safety mechanisms and charging interruptions, does the vehicle have a comprehensive safety mechanism? When abnormal temperature data is detected, will the vehicle trigger the safety mechanism to immediately stop charging and record the abnormality log? Regarding defense measures and safety enhancement suggestions, the vehicle should have a strong temperature data verification mechanism to ensure that the received temperature data is consistent with the actual battery temperature. The authenticity of the temperature data can be verified by multi-sensor data fusion.

[0062] The vehicle should judge the rationality of temperature data based on the temperature change trend. A sudden sharp rise or fall in temperature may be a sign of falsified data, and the vehicle should be able to identify these anomalies.

[0063] The cooling system should have an intelligent response mechanism to avoid erroneous operations due to forged temperature data. Through multi-level temperature detection and confirmation mechanisms, the cooling system can still operate normally when attacked by forged data.

[0064] By falsifying battery temperature data, it is possible to test the vehicle's ability to handle and react to temperature changes during charging. This type of test can be used in the following scenarios: Security testing of public charging stations: Testing whether vehicles in public charging stations can maintain charging safety under attacks using forged temperature data.

[0065] Safety of fleet charging management: Ensure that during large-scale fleet charging management, vehicles will not cause safety hazards during charging due to falsified temperature data.

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

[0067] Regarding the forged charging status data and the cheating of the charging port's abnormal status data processing capability, it means that during the charging process, the forged charger status data is periodically sent to cheat the protocol stack and test the protocol stack's abnormality processing capability, which may deceive the vehicle to stop charging.

[0068] 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 of the charger, connection status, current and voltage.

[0069] The charging status data is used to monitor the entire charging process and ensure that the vehicle and charging pile can respond correctly in abnormal situations. For example, if an abnormal connection to the charging port is detected, the vehicle or charging pile will trigger a protection mechanism to pause or stop charging.

[0070] The test goal 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 processing capabilities when receiving abnormal status data.

[0071] The focus is on evaluating whether the protocol stack can correctly identify forged charging status data and whether the vehicle will make unreasonable responses based on incorrect status information (such as mistakenly stopping charging).

[0072] When capturing charging status data messages, a charging data collector is used to capture the charging status data messages exchanged between the vehicle and the charging pile during the charging process. Focus on information such as the charger status, connection status, current and voltage.

[0073] Common charging states include: Charger status: Indicates whether the charger is in working state, standby state, error state, etc.

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

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

[0076] By analyzing the captured messages, we can understand the structure of the charging status data, especially the fields related to the charger working status, connection status, etc.: Working status field: Indicates whether the charger is operating, charging is in progress, or is in an abnormal state.

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

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

[0079] Forging charger status data includes forging abnormal status: constructing a forged charger abnormal status message. For example, forging the charging pile to be in an overheated or faulty state, deceiving the vehicle into believing that the charging pile can no longer provide stable charging services.

[0080] Fake standby state: simulate the charger suddenly entering the standby state, send a status message to the vehicle, fake the situation that the charging pile stops supplying power, and test whether the vehicle will stop charging based on this.

[0081] Fake connection disconnection: During the charging process, fake the connection status as "disconnected" and send a message to the vehicle to test whether the vehicle will think that the connection between the charging port and the charging pile is disconnected and stop charging immediately.

[0082] Forging unstable connection: Forging an unstable connection state, simulating a poor physical connection at the charging port, sending intermittent forged "disconnection" and "reconnection" states to the vehicle to test the vehicle's response.

[0083] Forging excessively high current / voltage data: Constructing forged messages indicating that the current or voltage exceeds the safe range, simulating that the current or voltage output by the charging pile is too high, and testing whether the vehicle will stop charging or trigger a protection mechanism based on this information.

[0084] Forged low current / voltage data: simulate the insufficient output power of the charging pile, send forged low current or voltage messages, and test the vehicle's ability to handle low power conditions.

[0085] During the charging process, a charging data collector is used to construct forged charging status data and periodically send this data to the vehicle. By continuously sending forged abnormal status data, the vehicle's ability to handle these abnormal signals is observed. Forged data may include charger overheating, disconnection, or abnormal working status of the charging pile.

[0086] Observe whether the vehicle exhibits the following behaviors after receiving the fake charging status data: Stop Charging: Can the vehicle mistakenly stop charging due to falsified status data? Power adjustment: Will the vehicle automatically adjust charging power due to falsified current / voltage abnormal data? Alarm Triggering: Will the vehicle trigger an erroneous alarm system or safety mechanism based on fabricated abnormal status data? Logging: Are error logs related to forged abnormal conditions recorded in the vehicle's internal systems? Is there a mechanism to verify the charging status data between the vehicle and the charging station? For example, when the forged charging status is inconsistent with the actual status perceived by the vehicle, will the protocol stack detect and ignore the forged message? When the protocol stack receives forged abnormal charging status data, can it handle it properly and prevent the charging process from being affected? For example, will the protocol stack perform multiple verifications before the wrong status data triggers charging to stop? When the protocol stack detects a forged abnormal charging state, will it trigger a safety mechanism to prevent forged data from damaging the charging process? For example, will the protocol stack confirm whether the charging state is abnormal through repeated verification or feedback mechanisms and take appropriate countermeasures? For defense measures and security enhancement recommendations, 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. The encryption mechanism ensures that the charging status data will not be tampered with by attackers.

[0087] The protocol stack should ensure the accuracy of charging status information based on multiple status data verification mechanisms. For example, the status data of the vehicle's own sensors and the feedback information of the charging pile can be combined to verify the authenticity of the status message.

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

[0089] For application scenarios, including: Safety testing of public charging stations: ensuring that vehicles in public charging stations do not interrupt charging or trigger erroneous protection mechanisms due to falsified charging status data.

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

[0091] Security of home charging stations: During home charging, ensure that the vehicle can detect falsified status data and respond appropriately, avoiding unnecessary charging interruptions.

[0092] Furthermore, the 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 also 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.

[0093] Furthermore, 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.

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

[0095] DDoS (distributed denial of service) attacks are attacks that send a large number of invalid requests to the target system to consume its resources and prevent it from responding to legitimate requests. In smart charging scenarios, DDoS attacks may affect the normal communication of charging piles or vehicles, causing the charging process to be interrupted or delayed. Before and during charging, DDoS attacks on vehicles or charging piles may cause system overload, affecting the safety and reliability of charging.

[0096] The test goal is to verify the ability of vehicles and charging piles to resist DDoS attacks by sending a large number of invalid messages in a short period of time. The system's performance under DDoS attacks, including response time, charging interruption, and any possible safety alerts, is observed.

[0097] During the charging process, use a charging data logger 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 normal communication messages and determine important fields such as frame ID, data length, and DID.

[0098] Identify key communication messages between the vehicle and the charging pile during the charging process so that when conducting DDoS testing, these specific types of messages can be sent in large quantities.

[0099] Forge a large number of invalid charging request messages. These messages can be: Incorrectly formatted messages: intentionally using a format that does not comply with the protocol in order to cause system errors or exceptions; False charging requests: Forged charging requests, including parameters that exceed the carrying capacity of the battery or charging pile.

[0100] During the attack phase, a large number of forged messages are generated and sent quickly in a short period of time. This can be achieved through automated tools or scripts to achieve high concurrency sending of a large number of messages in a short period of time.

[0101] Before and during charging, launch a DDoS attack to send a large number of invalid messages to the vehicle and charging pile; Record the number of messages sent, their frequency, and duration to analyze the intensity of the attack.

[0102] Observe the reactions of vehicles and charging piles when facing DDoS attacks: Response time: Whether the time it takes for the system to respond to normal requests increases significantly and whether the charging process is affected.

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

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

[0105] 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.

[0106] 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?

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

[0108] 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.

[0109] 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.

[0110] For application scenarios, including: 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.

[0111] 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.

[0112] Safety of home charging equipment: Test the stability of home charging piles under high traffic conditions to ensure the charging safety of home electric vehicles.

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

[0114] Before the vehicle and the charging pile charge, in addition to the handshake protocol, there will be a parameter configuration stage. This stage involves the configuration of charging-related parameters such as current, voltage, power, and sometimes system time synchronization.

[0115] The vehicle and the charger need to synchronize system time so that a consistent time base is used in communication, error logging, and future charging operations. This is critical for recording charging events and performing tasks such as scheduling.

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

[0117] Fake data can include compressed time data (such as shortened timestamps) or uncompressed time data (such as using an incorrect format) to test the vehicle's ability to handle different time data formats.

[0118] During the charging parameter configuration phase, messages containing time information are exchanged between the vehicle and the charging station. Use a charging data logger to capture and record these messages, focusing on the fields containing time data. These messages usually contain timestamps, synchronization identifiers, or other time parameters in periodic communications so that both parties can maintain a consistent system time.

[0119] By analyzing normal time synchronization messages, the format of the time data is determined, including: Timestamp: A time identifier usually in seconds or milliseconds, used to record the specific moment when charging starts, ends, or is interrupted.

[0120] Compressed time data: Sometimes protocols use compressed timestamps (i.e., simplified time units) to reduce the burden of data transmission.

[0121] Uncompressed time data: Use a timestamp in a standard format, such as UTC or local timestamp.

[0122] After that, compressed and uncompressed forged time data are constructed, where compressed time data spoofing includes forging a compressed time data packet, for example, shortening the current time to an incorrect value (such as deleting the millisecond part of the timestamp), so that the vehicle receives an incomplete time synchronization information. This type of forged data may cause inaccurate time records or time jumps in the vehicle, especially when recording charging logs.

[0123] Uncompressed time data spoofing involves constructing an uncompressed time data packet that contains 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 logging and event triggering during charging.

[0124] After the vehicle completes parameter configuration and enters the charging preparation phase, use the charging data collector to send fake time synchronization data to the vehicle. You can simulate a continuous time synchronization attack by periodically sending compressed or uncompressed time data. Use the same message format and communication protocol to make the vehicle mistakenly believe that these fake time data come from the charging pile.

[0125] Observe the vehicle’s behavior after receiving falsified time data, especially its response in terms of time synchronization and charging logging.

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

[0127] In order to verify the time synchronization capability of the vehicle, a time synchronization protection mechanism is adopted, including timestamp verification: whether the vehicle can verify the validity of the received timestamp. For example, will it check whether the timestamp is within a reasonable range, or whether it matches the local time of the charging station. Time format verification: Will the vehicle 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: if invalid time data is received, will the vehicle continue to use the last synchronized time, or will it fall back to the default time? Will the error of time synchronization failure be recorded in the log, or will the user or maintenance personnel be prompted through the alarm system? To prevent time synchronization data from being forged or tampered with, time data should be transmitted using encryption technology (such as TLS / SSL). At the same time, the message should contain integrity checks (such as HMAC) to ensure that the data has not been tampered with.

[0128] Upon receiving the time synchronization data, the vehicle shall perform rigorous validation including: Timestamp range check: Ensure that the received timestamp is within a reasonable range (e.g., not too much or too little beyond the current time).

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

[0130] If an abnormality in 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.

[0131] For application scenarios, including: Time management in public charging stations: Ensure that the time synchronization mechanism in public charging stations is not vulnerable to attacks and avoid time recording errors.

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

[0133] Log management of home charging stations: In the home charging system, ensure the consistency of time records between vehicles and charging piles to avoid deviations in future data analysis.

[0134] Furthermore, 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, EFF ID, 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.

[0135] In this embodiment, for the above-mentioned related parameters, refer to Table 1-10.

[0136] Table 1 CAN configuration information table

[0137] Table 2 Startup test operation parameters

[0138] Table 3 Task stop conditions

[0139] Table 4 Interoperability test operation parameters

[0140] Table 5 Packet capture settings

[0141] Table 6 Periodic message configuration table

[0142] Table 7 Receiving filter rules

[0143] Table 8 Detection use case configuration table

[0144] Table 9 External command configuration table

[0145] Table 10 Engine configuration table

[0146] Refer to Table 11-12, run the test cases with relevant parameters, and obtain the corresponding test results.

[0147] Table 11 Test results

[0148] Table 12 Test case table

[0149] Furthermore, the method further comprises: When the vehicle to be tested starts charging, the vehicle data is forged, a data message for stopping charging is forged, and 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, the vehicle to be tested is deceived into starting charging.

[0150] Furthermore, when the vehicle to be tested stops 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, constructs test data, and deceives the vehicle into starting 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 a forged message includes using message freshness verification, handshake verification, timestamp verification or other safety measures to prevent unauthorized charging start; If the vehicle to be tested verifies the freshness of the message, outdated or repeated start commands are rejected.

[0151] 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.

[0152] Among them, in this embodiment, when charging is stopped, the vehicle is deceived to start charging, that is, the charging data acquisition instrument is connected to the vehicle charging port and the charging gun respectively, and the charging is started by scanning or swiping the card, and the charging is stopped after about two minutes. At this time, the test data is constructed to deceive the vehicle to stop charging.

[0153] The vehicle and the charging pile communicate through a standard charging protocol (such as CHAdeMO, CCS or GB / T, etc.). When starting charging, the charging pile shakes hands with the vehicle and exchanges the power transmission protocol. 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.

[0154] Use a charging data logger to capture and record all communication data within two minutes of charging, especially the messages when charging starts and stops. Important information includes: Frame ID: used to identify the data stream of each message.

[0155] Message content: such as handshake information, charging status, error code, etc.

[0156] Current and voltage information: messages used to transmit power-related information.

[0157] When charging stops, a series of stop charging signals will be exchanged between the vehicle and the charging pile. The collector should record these signals and analyze the message and specific data field when charging stops, especially the command or event identifier of stop charging.

[0158] Analyze the message differences when charging starts and stops, focusing on: Handshake protocol: Confirm the specific steps to start charging.

[0159] Start and stop conditions: Analyze whether there is a specific identifier in the stop charging message, and whether there are start commands or recharging conditions that can be forged.

[0160] DID vs. Frame ID: Identify the frame ID and data identifier (DID) associated with starting and stopping charging, which are the key to subsequent simulation data.

[0161] Based on the handshake protocol and startup process analyzed previously, a simulation message is constructed using the collector to simulate the charging pile resending the start charging command to the vehicle.

[0162] Frame ID: Use the frame ID associated with starting charging.

[0163] Simulate message content: Construct a message similar to the actual start-up charging, imitating the start signal and current and voltage requests in the handshake protocol.

[0164] Power parameters: The current and voltage values ​​can be modified or falsified appropriately to keep them consistent with those when starting charging.

[0165] After charging stops, the collector sends a constructed forged message to the vehicle to simulate the charging pile to restart the charging request. By using the same frame ID and DID, the vehicle thinks that the charging pile has restarted the handshake.

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

[0167] If the vehicle restarts to charge, the system does not have sufficient authentication mechanisms and accepted a false start signal.

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

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

[0170] Message freshness: If the vehicle verifies message freshness, outdated or duplicate start commands may be rejected.

[0171] Handshake Verification: Some systems may require a re-handshake to confirm a safe state, and if the forged message lacks critical handshake information, the vehicle may refuse to recharge.

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

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

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

[0175] Targeting specific applications in implementation, including: Public charging station security: Prevent malicious attackers in public charging stations from forging start signals and inducing vehicles to charge illegally.

[0176] Home charging pile protection: Tests the security of home charging equipment after charging stops, preventing the communication between the charging pile and the vehicle from being tampered with, resulting in unnecessary recharging.

[0177] Enterprise fleet management system: In large-scale electric vehicle fleet management, it prevents unnecessary charging consumption and waste of system resources, and ensures the safety of the charging process.

[0178] Furthermore, the method further comprises: 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.

[0179] Among them, in this embodiment, deceiving the vehicle protocol version is to forge the protocol stack version data during the charging handshake phase to verify the vehicle protocol stack's abnormal handling capability.

[0180] Before the vehicle and the charging pile are charged, the two parties will handshake through the 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. Protocol stack version information is exchanged during the handshake phase to ensure that the charging protocols used by both parties are compatible. If the protocol versions of the vehicle or the charging pile are incompatible, charging may not start normally or may be interrupted.

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

[0182] Use a charging data logger to capture all communication messages exchanged between the vehicle and the charging pile during the charging handshake phase. Focus on the message fields containing protocol stack version information, such as version number, function bit identifier, etc.

[0183] 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 identified.

[0184] The version number included in the handshake message is used to ensure communication compatibility between the charger and the vehicle. This may include: Protocol stack major version number: identifies the major version of the charging protocol (such as 1.0, 2.0, etc.).

[0185] Protocol stack minor version number: used to distinguish different minor versions under the same major version.

[0186] Feature Bits: Indicates the supported feature set, such as specific voltage or current support.

[0187] In the handshake phase, the protocol stack version data is usually included as part of the handshake message. By analyzing the normal handshake data, the frame ID, data length, DID (data identifier), etc. of the protocol stack version can be determined.

[0188] The version information usually consists of multiple bytes, each byte identifying the major version number, minor version number, or specific feature support information.

[0189] Use a collector to construct forged version data. Version information can be forged in the following ways: Version number is too low: Forge a version number lower than the vehicle protocol stack version to test how the vehicle handles unsupported old versions.

[0190] Version number is too high: Forge a version number higher than the version number supported by the vehicle to test the vehicle's response when it cannot support the version.

[0191] Randomize version number: Enter a completely invalid or random version number to test the vehicle's fault tolerance mechanism.

[0192] In addition to forging version numbers, the functions supported by the protocol stack can also be forged by modifying the function bits. For example, forging support for certain incompatible voltage, current or safety certification functions to test whether the vehicle will correctly handle these incorrect function declarations.

[0193] During the handshake phase, the charging data logger inserts fake protocol stack version data to simulate inconsistent or incorrect protocol version information sent by the charging pile. Make sure the fake version number is incompatible with the vehicle to observe how the vehicle handles the situation.

[0194] Observe whether the vehicle starts charging normally or reports an error after receiving the forged protocol stack version data.

[0195] If the vehicle has a version verification mechanism, it may refuse to charge and report an error that the protocol version does not match.

[0196] If the vehicle does not have a valid authentication mechanism, charging may start but exhibit abnormal behavior or stop charging.

[0197] Verify the vehicle's anomaly handling capabilities using anomaly detection mechanisms, including: Version verification mechanism: Whether the vehicle can detect version mismatch or functional bit abnormality during the handshake phase and interrupt charging in time.

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

[0199] Downgrade mechanism: Some vehicles may have a protocol version downgrade mechanism (such as falling back to an older supported version). Test whether the vehicle has such functionality.

[0200] The speed at which a vehicle reacts when it detects an anomaly (such as interrupting the handshake protocol, refusing to start charging) is an important indicator for evaluating its safety and robustness. If the vehicle responds slowly or does not handle errors in a timely manner, it may lead to potential safety hazards.

[0201] The vehicle should have a strict protocol stack version verification mechanism to ensure that the handshake process can be interrupted in time when the protocol stack version is incompatible to prevent erroneous charging operations.

[0202] 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 is possible to effectively prevent forged version numbers or function bits from being injected into the communication stream.

[0203] In the case of incompatible protocol versions, the vehicle should have an automatic downgrade mechanism, that is, fall back to a lower version of the protocol supported by both parties to ensure that the charging process can still be carried out safely.

[0204] For application scenarios, including: Public charging station security: Tests whether there are incorrect protocol version numbers or function declarations in public charging stations to ensure that vehicles are not attacked by forged charging station version numbers.

[0205] Fleet charging management: For large fleets, ensure that the charging system of each vehicle can correctly handle inconsistent protocol versions to avoid charging interruptions or unsafe charging.

[0206] Home charging station: Test whether the protocol version of the home charging station meets the requirements of the vehicle and ensure the security of the protocol handshake process.

[0207] Among them, in this embodiment, it also includes: when charging is not started, deceiving the vehicle to start charging; Reference Figure 2 When the charging pile is charging the intermediate device normally, the vehicle sends a stop signal to the intermediate device normally. At this time, the CAN signal is intercepted to simulate the continue charging signal and send it to the charging pile, thereby sending a continue charging simulation signal to the charging pile.

[0208] After the charging data collector is connected to the vehicle's charging port and the charging gun respectively, the charging gun starts low-voltage auxiliary power supply (12V). Charging does not start at this time. The collector receives normal charging messages, analyzes the target frame ID, message length, DID, etc. sent by the message, and simulates the message data and sends it to the same frame ID to check whether the vehicle has message freshness verification.

[0209] After the vehicle is connected to the charging pile, but before high-voltage charging begins, the charging gun will start low-voltage auxiliary power supply (usually 12V). This is to ensure the stability of the initial communication and to confirm data exchange and handshake protocols.

[0210] During auxiliary power supply, the vehicle and the charging pile will exchange data messages through the CAN bus or other protocols. The charging data logger can capture these messages and analyze their structure and content.

[0211] Frame ID: A unique identifier of a message, used to distinguish different data streams.

[0212] Message length: Specifies the byte length of the data segment, which may vary depending on the frame ID.

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

[0214] The collector captures this data and understands the communication mode between the vehicle and the charging gun.

[0215] After collecting normal charging messages, the collector needs to analyze the structure of the messages: Target frame ID: used to identify the recipient of the message (for example, the charging control unit of the vehicle).

[0216] Message length: Ensure that the simulated message length is consistent with the original message to avoid format errors at the protocol layer.

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

[0218] Based on the analysis results, the collector 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 consistent, the purpose is to test whether the vehicle can identify forged, outdated or duplicate messages.

[0219] The collector sends a simulated message to the vehicle, using the same frame ID as the original message, which means that 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 responds, or whether it ignores the message.

[0220] 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.

[0221] Timestamp: Many messages contain a timestamp, and the system ensures the timeliness of the message by verifying the timestamp.

[0222] Counter: Some protocols attach counters to messages to track the order in which messages are sent and to ensure that messages are not repeated or forged.

[0223] Message Digest: Some messages may use cryptographic techniques (such as hashing or MAC) to verify the integrity and origin of the message.

[0224] By sending a simulated fake message, 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 the previous message or outdated and discard it.

[0225] If the vehicle ignores the simulated message, the vehicle has performed a freshness verification.

[0226] If the vehicle accepts the simulated message and responds, it indicates that the vehicle may not perform freshness verification or there is a vulnerability in the verification mechanism.

[0227] Targeting specific applications in implementation, including: Public charging pile environment: Test whether the public charging pile has a mechanism to prevent message replay or forgery when communicating with the vehicle to improve charging safety.

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

[0229] Electric vehicle fleet management: When the vehicles are charging, the security of the messages is tested to ensure that there are no communication loopholes in the charging process of the entire fleet, thus ensuring the safe charging of electric vehicles.

[0230] Among them, this embodiment also includes deceiving the vehicle to stop charging when starting charging, that is, the charging data collector is connected to the vehicle charging port and the charging gun respectively, scanning or swiping the card to start charging, constructing CHM test data, and deceiving the vehicle to stop charging.

[0231] First, the CHM test data deceives the vehicle into stopping charging. CHM (Charging Handshake Message) is part of the charging protocol and is responsible for handshaking at the beginning of charging to ensure that the connection and communication between the vehicle and the charging pile are safe and effective. If the handshake fails, charging will not be possible or will be interrupted; The charging data collector connects to the vehicle's charging port and charging gun to capture and record all communication data between the two parties in real time, especially the CHM data in the handshake protocol stage; Analyze CHM data and identify the information exchanged between the two parties during the handshake process, such as voltage and current parameters, error codes, and communication status.

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

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

[0234] Use a charging data collector to insert fake CHM test data into the real charging communication flow.

[0235] This can be achieved by interrupting the real data exchange and replacing or inserting fake data packets. The goal is for the vehicle to detect communication anomalies or parameter errors, triggering its protection mechanism and automatically stopping charging.

[0236] A forged CHM data packet will cause the vehicle to believe that there is a problem during the charging process, such as a communication failure or a security threat, and will automatically stop the charging process.

[0237] Once the vehicle stops charging, the system may require re-handshake or detect an abnormality and record an error message.

[0238] During security defense, authentication and encryption are performed: 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 secure handshake protocols (such as TLS / SSL) to prevent the insertion of forged messages; Data integrity check: Perform integrity checks on data packets during the charging process to ensure that all communication data has not been tampered with; Abnormal detection: Vehicles and charging piles can design abnormal detection mechanisms to issue alarms or record detailed logs for subsequent analysis when suspicious or invalid handshake messages are detected.

[0239] Specific applications for implementation scenarios include: Public charging stations: Through data acquisition devices, attacks are carried out while vehicles are charging, inducing the vehicles to stop charging, causing inconvenience to users.

[0240] Disruption of communication between vehicles and private charging piles: Attacks are carried out on charging piles used at home or in enterprises, resulting in the inability to complete charging tasks. Fleet charging management system: In the fleet charging system, attacks are carried out on the communication between vehicles, resulting in charging interruptions, thus affecting the normal use and operational efficiency of the vehicles.

[0241] According to a second embodiment of the present invention, the present invention claims protection for a safety testing system for vehicle charging interface information, comprising: one or more processors; 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.

[0242] In the 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 only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0243] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units. The above is only an implementation mode of the present invention, and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the present invention specification and drawings, or directly or indirectly used in other related technical fields, is also included in the patent protection scope of the present invention.

[0244] The specific implementation methods of the invention are described in detail above, but they are only examples, and the invention is not limited to the specific implementation methods described above. For those skilled in the art, any equivalent modification or substitution of the invention is also within the scope of the invention, therefore, the equalization, modification, improvement, etc. made without departing from the spirit and principle of the invention should be included in 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; Based on 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.

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, EFF ID, 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 1, characterized in that: Also includes: 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, the vehicle to be tested is deceived into starting charging.

8. A safety testing method for vehicle charging interface information according to claim 7, characterized in that: 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 to be tested verifies the freshness of the message, then outdated or repeated start commands are rejected; 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.

9. A safety testing method for vehicle charging interface information according to claim 8, 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.

10. 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 9.

Images