Vehicle-mounted network security communication detection method, system, device, medium and equipment

Abstract

The invention provides a vehicle-mounted network security communication detection method, system and device, a medium and equipment, and relates to the technical field of communication. According to the method, safety protocol data units on at least one target CAN bus of a vehicle end are obtained, vehicle-mounted safety communication verification is carried out on each safety protocol data unit, and then a detection report is formed based on the safety protocol data units which fail in verification. Therefore, the verification test of the security protocol data unit is accurately completed, the problem that a tester cannot locate a verification failure source of the security protocol data unit in a large amount of data can be solved, the test accuracy is improved, and omission caused by manual analysis is avoided.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, system, device, medium and equipment for detecting vehicle-mounted network security communication. Background Art

[0002] In recent years, automobile technology has developed rapidly in the direction of intelligence, electrification, networking, and sharing. The number, connection, and interaction of electronic devices inside vehicles have also continued to increase, gradually forming an in-vehicle communication network represented by the controller area network CAN (Controller Area Network), the local interconnection network LIN (Local Interconnection Network), FlexRay (in-vehicle network communication standard), the multimedia transmission system MOST (Media Oriented Systems Transport), and in-vehicle Ethernet. Among them, the CAN protocol is widely used in the internal communication of various controllers in automobiles because of its built-in CRC check (Cyclic Redundancy Check), but due to its plain text transmission and broadcast characteristics, there is a risk of message forgery and command replay.

[0003] In response to the communication security issues between ECUs of vehicle components, AUTOSAR (Automotive Open System Architecture) proposed SecOC (Security Onboard Community) to solve the problems of message replay, message content verification, and message timing verification. Generally, components can implement related security functions by integrating SecOC's SDK (Software Development Kit) to improve the communication security quality of the entire vehicle.

[0004] However, in an in-vehicle network environment such as the CAN bus, multiple ECUs (Electronic Control Units) will send and receive a large number of PDUs (Protocol Data Units) at the same time. These PDUs are sent in the form of broadcasts on the bus without a specific receiver address. Therefore, when the SecOC security mechanism detects a problem, it is difficult to accurately identify which frame of data has an abnormality from the numerous PDUs, which brings great inconvenience to developers or maintenance personnel. Summary of the invention

[0005] The present application provides a vehicle-mounted network security communication detection method, system, device, medium and equipment, which can automatically verify the safety PDU on the CAN bus, and record and feedback the safety PDU that fails the verification, thereby reducing the burden on maintenance personnel.

[0006] A first aspect of an embodiment of the present application provides a method for detecting vehicle-mounted network security communication, the method comprising:

[0007] Acquire a safety protocol data unit on at least one target CAN bus on the vehicle side;

[0008] Performing on-vehicle safety communication verification on each of the safety protocol data units;

[0009] A detection report is generated based on the security protocol data unit that fails verification.

[0010] Optionally, obtaining a safety protocol data unit on at least one target CAN bus on the vehicle side includes:

[0011] Obtain a data transmission list corresponding to any of the target CAN buses;

[0012] The security protocol data unit is obtained by screening from the data transmission list based on a preset rule.

[0013] Optionally, performing an on-board safety communication verification on each of the safety protocol data units includes:

[0014] Parsing any of the security protocol data units to obtain corresponding original data, original freshness value and original authentication information;

[0015] Generate local authentication information based on the original data, the ID of the original data, and the to-be-verified freshness value corresponding to the ID of the original data;

[0016] When the local authentication information is consistent with the original authentication information, it is determined that the security protocol data unit verification succeeds; when the local authentication information is inconsistent with the original authentication information, it is determined that the security protocol data unit verification fails.

[0017] Optionally, a detection report is formed based on the security protocol data unit that fails verification, including:

[0018] Recording any security protocol data unit that fails verification according to a preset format;

[0019] The records of the safety protocol data units that failed verification on at least one target CAN bus are summarized to form the detection report.

[0020] Optionally, recording any security protocol data unit that fails verification according to a preset format includes:

[0021] The safety protocol data unit is recorded based on the ID of the safety protocol data unit that fails verification, the ID of the target CAN bus corresponding to the safety protocol data unit, and the corresponding verification time.

[0022] Optionally, the method further comprises:

[0023] In response to the fault reading instruction, reading the current fault code of the receiver corresponding to the safety protocol data unit that failed the verification;

[0024] In the case where the current fault code is read, determining that the vehicle safety communication function of the receiver is normal;

[0025] In the case where the current fault code is not read, it is determined that the vehicle-mounted safety communication function of the recipient is abnormal.

[0026] Based on the same inventive concept, the second aspect of the embodiment of the present application provides a vehicle-mounted network security communication detection system, the system comprising: a vehicle end, a bus acquisition device and a terminal device; one end of the bus acquisition device is connected to the terminal device, and the other end of the bus acquisition device is connected to the target CAN bus in the vehicle end; wherein,

[0027] The bus acquisition device is used to collect the safety protocol data unit on the target CAN bus and send it to the terminal device;

[0028] The terminal device is used to execute the vehicle-mounted network security communication detection method described in the first aspect above.

[0029] Based on the same inventive concept, a third aspect of an embodiment of the present application provides a vehicle-mounted network security communication detection device, the device comprising:

[0030] A data acquisition module, used to acquire a safety protocol data unit on at least one target CAN bus on the vehicle side;

[0031] A data verification module, used for performing on-board safety communication verification on each of the safety protocol data units;

[0032] The data recording module is used to generate a detection report based on the security protocol data unit that fails the verification.

[0033] Based on the same inventive concept, the fourth aspect of an embodiment of the present application provides a storage medium, which stores machine executable instructions. When the machine executable instructions are executed by a processor, the vehicle-mounted network security communication detection method proposed in the first aspect of the present application is implemented.

[0034] A fifth aspect of an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements the in-vehicle network security communication detection method proposed in the first aspect of the present application.

[0035] Compared with the prior art, this application has the following advantages:

[0036] The embodiment of the present application provides a vehicle-mounted network security communication detection method, which obtains the security protocol data unit on at least one target CAN bus on the vehicle side, performs vehicle-mounted security communication verification on each security protocol data unit, and then forms a detection report based on the security protocol data unit that failed the verification. Thus, the test of the security protocol data unit verification is accurately completed, which can solve the problem that the tester cannot locate the source of the security protocol data unit verification failure in a large amount of data, improve the test accuracy, and avoid omissions caused by human analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0038] Figure 1 This is the system architecture diagram of the SecOC module;

[0039] Figure 2 This is the internal principle block diagram of the SecOC module;

[0040] Figure 3 is a flow chart of a vehicle-mounted network security communication detection method in one embodiment of the present application;

[0041] Figure 4 This is a functional module diagram of a vehicle-mounted network security communication detection system in one embodiment of the present application;

[0042] Figure 5 This is a schematic diagram of the scene layout of vehicle-mounted network security communication detection in one embodiment of the present application;

[0043] Figure 6 This is a functional module diagram of a vehicle-mounted network security communication detection device in one embodiment of the present application;

[0044] Figure 7 It is a structural schematic diagram of an electronic device in one embodiment of the present application. DETAILED DESCRIPTION

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

[0046] Please refer to Figure 1 , Figure 1 This is the system architecture diagram of the SecOC module. Figure 1 As shown, the ECU implementing the SecOC security mechanism is provided with a SecOC module. When data transmission and interaction are performed between two ECUs implementing the SecOC security mechanism, it is assumed that ECU1 is the data sender and ECU2 is the data receiver. ECU1 will pass the PDU (protocol data unit) of its upper-layer application to the PDUR (Protocol Data Unit Router) module, which will route the PDU to the SecOC module, and add authentication information to the PDU through the SecOC module to create a secure PDU. Among them, the authentication information includes the freshness value (FreshnessValue, referred to as FV) and the message authentication code (Message Authentication Code, referred to as MAC). Then, the secure PDU with the authentication information added is passed to the CAN bus, received by the PDUR module of ECU2 and routed to the SecOC module of ECU2, and the authentication information of the received secure PDU is verified. If the verification is successful, the original data PDU is uploaded to the software module of the upper-layer application. If the verification fails, it is directly discarded and a fault code is fed back.

[0047] For details, please refer to Figure 2 , Figure 2 This is the internal principle block diagram of the SecOC module. Figure 2 As shown, when the sender's SecOC module processes the PDU data, it obtains the freshness value (FV) from the freshness value management module on the one hand, and uses the key and PDU data (including FV) to calculate the message authentication code (MAC) on the other hand. In order to reduce the consumption of resources such as bandwidth, the SecOC module will intercept part of the FV and MAC values ​​(such as the low-significant bits of the FV and the high-significant bits of the MAC value), and then encapsulate these intercepted values ​​together with the original PDU data into a secure PDU. When the receiver's SecOC module verifies the received secure PDU, it uses the same key and algorithm to calculate the MAC value and compares it with the MAC value parsed from the secure PDU. If they are consistent, the verification is passed, otherwise it is discarded.

[0048] In the existing technology, since performance and real-time performance are very important factors to consider in vehicle networks, the SecOC security mechanism usually weighs the relationship between security and performance, and ultimately tends to adopt a simpler and more efficient security verification mechanism. This also leads to some disadvantages of the SecOC security mechanism:

[0049] 1. The SecOC security mechanism focuses on whether the data itself has been tampered with and the freshness of the message, rather than the specific data content. Therefore, when MAC verification fails, it only means that the data may have been tampered with or replayed during transmission, but it cannot directly locate which specific frame of data has a problem.

[0050] 2. When MAC verification fails, the receiver usually discards the PDU or triggers the error handling mechanism, but does not provide specific error frame information.

[0051] 3. Currently, more and more ECUs are implementing the SecOC security mechanism. Each ECU will simultaneously send dozens of its own security PDUs to the CAN bus in millisecond cycles, which will cause thousands of security PDUs to appear on the bus. Therefore, when the SecOC security mechanism detects a problem, it is difficult to accurately identify which frame of data has an abnormality from the numerous PDUs. In addition, the processing of PDUs involves multiple layers and complex protocol stacks, which also increases the difficulty of directly locating the problem frame.

[0052] In view of this, the present application proposes a vehicle-mounted network security communication detection method, which obtains the security protocol data units on the CAN bus in real time for verification, records the security protocol data units that fail the verification, and feeds back to the tester, so that the tester can locate the source and time of the failure of the security protocol data unit verification in a large amount of data, so as to quickly locate the problem point and make corresponding repairs, thereby reducing system instability or data security problems caused by the failure of the security protocol data unit verification, and reducing the impact on business and users.

[0053] Please refer to Figure 1 , Figure 1 1 is a flow chart of a vehicle network security communication detection method proposed in one embodiment of the present application. Figure 1 As shown, the method comprises the following steps:

[0054] S101: Acquire a safety protocol data unit on at least one target CAN bus on the vehicle side.

[0055] In this embodiment, the target CAN bus refers to the CAN bus where the ECU involved in the vehicle safety communication (SecOC) function is located. The target CAN bus includes a power CAN bus, a safety CAN bus, an intelligent driving CAN bus, and the like.

[0056] The safety protocol data unit, or safety PDU, refers to the data obtained by adding authentication information to the original PDU data by the ECU with in-vehicle safety communication function. The safety PDU consists of the original PDU and the added freshness value (FV) and message authentication code (MAC). Among them, PDU (Protocol Data Unit) refers to the data unit used for information transmission between protocols at different levels in a computer network. PDU is the basic unit for exchanging information between protocols at different levels, and each PDU contains control information and data information. In network communication, each layer of protocol will add its own PDU header information and package the data to be transmitted into the PDU for transmission in the next layer of protocol. The format and content of each PDU are specified by different layer protocols, and different PDUs can carry different types of information, such as data, commands, control information, etc. For example, in an IP network, IP datagram is a form of PDU. Between the physical layer and the data link layer of the OSI model (OpenSystem Interconnect), there is also a form of PDU called frame.

[0057] S102: Performing vehicle safety communication verification on each safety protocol data unit.

[0058] In this embodiment, when the safety PDU is verified for on-board safety communication, the integrity and freshness of the data are mainly verified through the message authentication code (MAC) and the freshness value (FV). Among them, MAC is a cryptographic means for verifying the integrity of data, and the freshness value is used to prevent replay attacks.

[0059] Specifically, for any security PDU, the latest synchronized freshness value corresponding to the security PDU is obtained, and the message authentication code is recalculated based on the freshness value, and then the recalculated message authentication code is compared with the message authentication code contained in the security PDU itself. If the two are consistent, it means that the security PDU is authentic and has not been tampered with, and the security PDU verification is considered successful; if the two are inconsistent, it means that the security PDU has been tampered with or damaged during the transmission process, resulting in the receiver being unable to correctly verify the integrity of the data. At this time, the security PDU verification is considered to have failed. Failure of security PDU verification may indicate potential security threats in network communications, such as hacker attacks, malware, etc., which may attempt to steal, tamper with or destroy communication data. Therefore, if the security PDU verification failure is detected continuously, it needs to be processed as soon as possible to avoid waste of resources (such as retransmission, buffer occupancy, etc.) due to communication errors.

[0060] S103: Generating a detection report based on the security protocol data units that failed verification.

[0061] In this embodiment, the test report is formed by one or more verification failure records, which are used to feedback to the user the relevant information of the safety PDU that failed the verification. For example, any verification failure record contains the ID (IDentity, identity identifier) ​​of the safety PDU, the ID of the target CAN bus corresponding to the safety PDU, and the corresponding verification time and other information. In addition, the test report is updated in real time. Once a safety PDU fails to verify, the information related to the safety PDU is directly recorded and added to the test report to refresh the test report.

[0062] Furthermore, the test report can be scrolled through the interactive interface, making the information of the safety PDU that failed the verification more intuitive and easy to read, helping testers to quickly understand the type and severity of the problem. At the same time, through continuous scrolling display, it can ensure that every safety PDU that failed the verification is noticed, reducing the omission of faults due to negligence.

[0063] The existing SecOC security mechanism cannot provide specific error frame information when the security protocol data unit verification fails, so that the tester cannot directly locate which specific frame of data has a problem. However, this embodiment verifies the security protocol data unit on the CAN bus in real time, and records and feedbacks the security protocol data unit that fails the verification in real time, so as to promptly reflect the problems in network communication, so that network administrators or testers can immediately detect potential communication failures or security threats, and locate the source and time of the security protocol data unit verification failure in a large amount of data, quickly locate the source of the problem, and take corresponding solutions, thereby shortening the fault handling time, reducing potential data loss or security risks, and reducing the impact on business and users.

[0064] The following is another specific example to illustrate the detection process of a vehicle network security communication detection method proposed in this application:

[0065] S201: Obtain a data transmission list corresponding to any target CAN bus.

[0066] In this embodiment, by acquiring the data being transmitted on the target CAN bus, a data transmission list corresponding to the target CAN bus can be formed. The data transmission list includes both secure PDU data with added authentication information and some ordinary data without added authentication information. This embodiment mainly verifies the secure PDU data.

[0067] S202: Filter and obtain a security protocol data unit from the data transmission list based on a preset rule.

[0068] In this embodiment, the preset rules can be set based on the ID, data length or other characteristics of the transmitted safety PDU. For example, assuming that the data with IDs 1-10 are safety PDUs, the data with IDs 1-10 can be selected from the data transmission list by using a hardware or software filter to obtain the safety PDU to be verified, thereby reducing the amount of data to be processed.

[0069] S203: Parse any security protocol data unit to obtain corresponding original data, original freshness value and original authentication information.

[0070] In this implementation, after obtaining the security PDU being transmitted on the target CAN bus, the security PDU is first parsed to obtain the original data (i.e., original PDU), original freshness value (i.e., original FV), and original authentication information (i.e., original MAC) corresponding to the security PDU. For example, a security PDU consists of a 4-byte control signal, a 1-byte intercepted freshness value, and a 3-byte intercepted MAC value.

[0071] S204: Generate local authentication information based on the original data, the ID of the original data, and the to-be-verified freshness value corresponding to the ID of the original data.

[0072] In this implementation, a freshness value synchronization request message is first sent to the gateway master node to obtain the freshness value corresponding to the ID of the original data, that is, the freshness value to be verified, from the gateway master node. Then, based on the original data, the ID of the original data, and the synchronized freshness value to be verified, the authentication information is recalculated using the same key and algorithm as the sender of the secure PDU to obtain local authentication information.

[0073] Under normal circumstances, the obtained freshness value to be verified is the same as the freshness value obtained by the sender of the security PDU from the gateway master node. Therefore, the recalculated local authentication information should also be the same as the original authentication information. If the two are different, it means that there is a problem with the transmission of the data.

[0074] S205: When the local authentication information is consistent with the original authentication information, it is determined that the security protocol data unit verification is successful; when the local authentication information is inconsistent with the original authentication information, it is determined that the security protocol data unit verification fails.

[0075] In this embodiment, the data integrity of the security PDU can be determined by comparing the local authentication information with the original authentication information. If the local authentication information is consistent with the original authentication information, it means that the security PDU is authentic and has not been tampered with, and the security PDU verification is considered to be successful. Otherwise, if the local authentication information is inconsistent with the original authentication information, the security PDU verification is considered to have failed.

[0076] S206: Record any security protocol data unit that fails verification according to a preset format.

[0077] In this implementation manner, the preset format is in the form of a statistical table, which includes multiple recording elements such as the ID of the safety protocol data unit, the ID of the target CAN bus corresponding to the safety protocol data unit, and the corresponding verification time.

[0078] When a safety PDU that fails verification is detected, the ID of the safety protocol data unit, the ID of the target CAN bus corresponding to the safety protocol data unit, and the corresponding verification time are filled in the statistical table in sequence to form a verification failure record of the safety PDU.

[0079] S207: Summarize the records of the safety protocol data units that failed verification on at least one target CAN bus to form a detection report.

[0080] In this embodiment, when there are multiple target CAN buses, the verification failure records of one or more safety PDUs on each target CAN bus can be summarized separately to obtain a detection report corresponding to the target CAN bus, so that the test personnel can observe and understand, quickly locate the problem point and repair it in time.

[0081] S208: In response to the fault reading instruction, read the current fault code of the receiver corresponding to the safety protocol data unit that failed the verification, and determine whether the vehicle safety communication function of the receiver is normal.

[0082] In this implementation, when the current fault code is read, it is determined that the vehicle safety communication function of the receiver is normal; when the current fault code is not read, it is determined that the vehicle safety communication function of the receiver is abnormal.

[0083] For example, when a safety PDU that fails verification is detected, a 1902 service instruction can be sent to the receiver corresponding to the safety PDU to read the current fault code of the receiver corresponding to the safety PDU. If the verification result of the receiver for the safety PDU is also a failure as the verification result of this method, a current fault code DTC will be generated. Therefore, if the current fault code is read from the receiver, it means that the function of the SecOC module of the receiver ECU is normal. If the current fault code is not read from the receiver, it means that the function of the SecOC module of the receiver ECU is abnormal.

[0084] Therefore, for the safety PDU that fails verification, by reading the current fault code of the receiver corresponding to the safety PDU, it is possible to determine whether the function of the SecOC module of the receiver ECU is normal, which makes it easier for testers to discover and repair problems in a timely manner.

[0085] In addition, for some special scenarios, such as the target CAN bus busoff (the CAN bus enters a shutdown state, that is, the bus shutdown state, at which time the CAN node cannot send or receive messages), when it is just restored, the sender ECU and the receiver ECU may not be synchronized yet, but in this short process, due to the extremely small safety PDU cycle, the receiver ECU may have received several frames of safety PDU, but because it has not been synchronized, when the receiver ECU verifies these frames of safety PDU, the freshness value obtained is different from the freshness value used by the sender ECU of the safety PDU when it is packaged, and then the receiver ECU will produce a verification failure result and generate the current fault code. After the resynchronization is successful, under normal circumstances, the receiver ECU can correctly verify the safety PDU, and at this time, the fault code will be changed from the current fault code to the historical fault code.

[0086] Therefore, in such special scenarios, the function of the SecOC module of the receiving ECU can be judged by reading the current fault code and historical fault code of the receiving ECU. For example, during the busoff of the target CAN bus, if the current fault code is not read and the historical fault code is read, it is considered that the function of the SecOC module of the receiving ECU is normal, otherwise, the function of the SecOC module of the receiving ECU is abnormal.

[0087] Please refer to Figure 4 Based on the same inventive concept, the second aspect of the embodiment of the present application provides a vehicle-mounted network security communication detection system, which includes: a vehicle end 401, a bus acquisition device 402 and a terminal device 403; one end of the bus acquisition device 402 is connected to the terminal device 403, and the other end of the bus acquisition device 402 is connected to the target CAN bus in the vehicle end 401; wherein the bus acquisition device 402 is used to collect the safety protocol data unit on the target CAN bus and send it to the terminal device 403; the terminal device 403 is used to execute the vehicle-mounted network security communication detection method in the first aspect above.

[0088] In this embodiment, the vehicle end 401 refers to a constructed simulation test bench or a real vehicle, and the terminal device 403 refers to various terminals dedicated to specific communication and computing tasks, such as a personal computer (PC).

[0089] For details, please refer to Figure 5 , Figure 5 Schematic diagram of the scene layout of vehicle network security communication detection in one embodiment of the present application. Figure 5As shown, in this embodiment, the bus acquisition device 402 adopts a CANOE device (CAN Open Environment, bus development device). The CAN channel of CANOE is connected to the CAN bus where the ECU involved in the SecOC function in the actual vehicle is located through the OBD harness (used to connect the vehicle's OBD diagnostic interface and the diagnostic device, where OBD refers to On-Board Diagnostics, the vehicle diagnostic system). At the same time, the CANOE device is connected to the PC end (i.e., the USB cable) through the USB cable (Universal Serial Bus, universal serial bus) Figure 5 Connect the TESTER tester in the tester to correctly configure the CAN channel to facilitate data collection and transmission.

[0090] Among them, the PC is equipped with a network security PDU automatic verification test system script program to execute the vehicle-mounted network security communication detection method in the first aspect above, to monitor and verify the safety PDU on the CAN bus in real time, and to print the safety PDU that fails the verification on the panel, so that the tester can quickly locate the source and time of the safety PDU verification failure in a large amount of data, thereby improving the test accuracy and avoiding omissions caused by manual analysis.

[0091] As for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0092] Please refer to Figure 6 Based on the same inventive concept, the third aspect of the embodiment of the present application provides a vehicle-mounted network security communication detection device, the vehicle-mounted network security communication detection device 600 includes:

[0093] The data acquisition module 601 is used to acquire a safety protocol data unit on at least one target CAN bus of the vehicle end;

[0094] A data verification module 602 is used to perform on-board safety communication verification on each safety protocol data unit;

[0095] The data recording module 603 is used to generate a detection report based on the security protocol data unit that failed the verification.

[0096] Optionally, the data acquisition module 601 includes:

[0097] The transmission list acquisition submodule is used to obtain the data transmission list corresponding to any target CAN bus;

[0098] The data screening submodule is used to screen the security protocol data unit from the data transmission list based on preset rules.

[0099] Optionally, the data verification module 602 includes:

[0100] The parsing submodule is used to parse any security protocol data unit to obtain the corresponding original data, original freshness value and original authentication information;

[0101] A generating submodule, for generating local authentication information based on the original data, the ID of the original data, and the freshness value to be verified corresponding to the ID of the original data;

[0102] The verification submodule is used to determine that the security protocol data unit verification is successful when the local authentication information is consistent with the original authentication information, and to determine that the security protocol data unit verification fails when the local authentication information is inconsistent with the original authentication information.

[0103] Optionally, the data recording module 603 includes:

[0104] A single record submodule is used to record any security protocol data unit that fails verification according to a preset format;

[0105] The summary submodule is used to summarize the records of the safety protocol data units that failed verification on at least one target CAN bus to form a detection report.

[0106] Optionally, the single record submodule is specifically used for:

[0107] The safety protocol data unit is recorded based on the ID of the safety protocol data unit that failed the verification, the ID of the target CAN bus corresponding to the safety protocol data unit, and the corresponding verification time.

[0108] Optionally, the device further comprises:

[0109] A fault code reading submodule, configured to respond to a fault reading instruction and read a current fault code of a receiver corresponding to a safety protocol data unit that has failed verification;

[0110] The test submodule is used to determine that the vehicle safety communication function of the receiver is normal when the current fault code is read; and to determine that the vehicle safety communication function of the receiver is abnormal when the current fault code is not read.

[0111] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0112] In the fourth aspect, based on the same inventive concept, an embodiment of the present application provides a storage medium, which stores machine executable instructions. When the machine executable instructions are executed by a processor, the in-vehicle network security communication detection method proposed in the first aspect of the present application is implemented.

[0113] It should be noted that the specific implementation of the storage medium in the embodiment of the present application refers to the specific implementation of the vehicle-mounted network security communication detection method proposed in the first aspect of the embodiment of the present application, and will not be repeated here.

[0114] In the fifth aspect, based on the same inventive concept, refer to Figure 7 An embodiment of the present application provides an electronic device 700, including a processor 701 and a memory 702; the memory 702 stores machine executable instructions that can be executed by the processor 701, and the processor 701 is used to execute the machine executable instructions to implement the in-vehicle network security communication detection method proposed in the first aspect of the present application.

[0115] It should be noted that the specific implementation of the electronic device 700 in the embodiment of the present application refers to the specific implementation of the vehicle-mounted network security communication detection method proposed in the first aspect of the embodiment of the present application, and will not be repeated here.

[0116] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0117] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0119] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0120] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0121] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0122] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0123] The above is a detailed introduction to the vehicle-mounted network security communication detection method, system, device, medium and equipment provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A vehicle-mounted network security communication detection method, characterized in that: The method comprises: Acquire a safety protocol data unit on at least one target CAN bus on the vehicle side; Performing on-vehicle safety communication verification on each of the safety protocol data units; A detection report is generated based on the security protocol data unit that fails verification.

2. The method according to claim 1, characterized in that Acquiring a safety protocol data unit on at least one target CAN bus on the vehicle side, including: Obtain a data transmission list corresponding to any of the target CAN buses; The security protocol data unit is obtained by screening from the data transmission list based on a preset rule.

3. The method according to claim 1, characterized in that Performing on-board safety communication verification on each of the safety protocol data units includes: Parsing any of the security protocol data units to obtain corresponding original data, original freshness value and original authentication information; Generate local authentication information based on the original data, the ID of the original data, and the to-be-verified freshness value corresponding to the ID of the original data; When the local authentication information is consistent with the original authentication information, it is determined that the security protocol data unit verification succeeds; when the local authentication information is inconsistent with the original authentication information, it is determined that the security protocol data unit verification fails.

4. The method according to claim 1, characterized in that Based on the security protocol data unit that failed the verification, a detection report is formed, including: Recording any security protocol data unit that fails verification according to a preset format; The records of the safety protocol data units that failed verification on at least one target CAN bus are summarized to form the detection report.

5. The method according to claim 4, characterized in that Recording any security protocol data unit that fails verification according to a preset format, including: The safety protocol data unit is recorded based on the ID of the safety protocol data unit that fails verification, the ID of the target CAN bus corresponding to the safety protocol data unit, and the corresponding verification time.

6. The method according to claim 1, characterized in that The method further comprises: In response to the fault reading instruction, reading the current fault code of the receiver corresponding to the safety protocol data unit that failed the verification; In the case where the current fault code is read, determining that the vehicle safety communication function of the receiver is normal; In the case where the current fault code is not read, it is determined that the vehicle-mounted safety communication function of the recipient is abnormal.

7. A vehicle-mounted network security communication detection system, characterized in that: The system includes a vehicle end, a bus acquisition device and a terminal device; one end of the bus acquisition device is connected to the terminal device, and the other end of the bus acquisition device is connected to the target CAN bus in the vehicle end; wherein, The bus acquisition device is used to collect the safety protocol data unit on the target CAN bus and send it to the terminal device; The terminal device is used to execute the vehicle-mounted network security communication detection method described in any one of claims 1 to 6.

8. A vehicle-mounted network security communication detection device, characterized in that: The device comprises: A data acquisition module, used to acquire a safety protocol data unit on at least one target CAN bus on the vehicle side; A data verification module, used for performing on-board safety communication verification on each of the safety protocol data units; The data recording module is used to generate a detection report based on the security protocol data unit that fails the verification.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the vehicle-mounted network security communication detection method as described in any one of claims 1 to 6 is implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the in-vehicle network security communication detection method according to any one of claims 1 to 6 is implemented.

Images