CN115250184A

CN115250184A - Firewall white list updating and testing method, device, storage medium and vehicle

Info

Publication number: CN115250184A
Application number: CN202110376659.7A
Authority: CN
Inventors: 史青松; 余剑; 李占坤
Original assignee: SAIC General Motors Corp Ltd; Pan Asia Technical Automotive Center Co Ltd
Current assignee: SAIC General Motors Corp Ltd; Pan Asia Technical Automotive Center Co Ltd
Priority date: 2021-04-08
Filing date: 2021-04-08
Publication date: 2022-10-28

Abstract

The invention discloses a firewall white list updating and testing method, firewall white list updating and testing equipment, a storage medium and a vehicle. The firewall white list updating and testing method comprises the following steps: acquiring an updated white list file; automatically generating an updated white list library file code based on the white list file to produce an updated white list module; and automatically testing the code of the updated white list module to generate a test report. According to the vehicle firewall updating and testing method, device, storage medium and vehicle, optimization can be performed on a system level, so that the working efficiency is improved, the time for code development and maintenance is shortened, the stability and reliability of software are improved, and the risk that errors are easily caused when codes are updated manually is reduced.

Description

Firewall white list updating and testing method, device, storage medium and vehicle

Technical Field

The invention relates to the technical field of automobile safety. In particular, the invention relates to a firewall white list updating and testing method, device and storage medium for a vehicle and the vehicle with the device.

Background

To protect the automotive communication bus from Network attacks, related art solutions based on Controller Area Network (CAN) analysis are attracting increasing attention and interest from the industry. Meanwhile, in terms of cost and application considerations, enterprises have begun to start the secure upgrade of existing automobile part products.

From the physical protection point of view, a CAN transceiver with good performance is generally adopted to ensure the reliability of data transmission, and such CAN transceiver has the characteristics of Electromagnetic (EM) interference resistance, low electromagnetic radiation, electrostatic discharge (ESD) protection, fault tolerance, protection in the hot plug process, and the like. From the software protection perspective, a firewall is generally used to filter misformatted or aggressive CAN messages.

In a finished vehicle communication system, a Diagnostic Link Connector (DLC) and an infotainment system or a telematics system are used as interfaces for communication between a finished vehicle and an external network, and are external interfaces with the highest threat level in terms of security definition; physical module type isolation is often required to protect it from direct intrusion of external threats into the vehicle interior communication system. Under the condition that a firewall is selected to realize the software protection isolation function, the CAN buses in the vehicle CAN be guaranteed to be subjected to network segmentation, intrusion detection on data on each path of CAN bus and access control of a diagnosis port CAN be realized.

The CAN messages CAN be judged for safety in the filtering type firewall software according to a white list, and the white list CAN be composed of IDs of the CAN messages which are considered to be safe, reliable or needing to pass through the firewall in each path of CAN messages. The whitelist may be stored as a software module, the code of which needs to be updated in time following the update of the whitelist protocol (e.g., when protocol a is removed from the whitelist protocol, CAN messages communicated using protocol a should also be removed from the whitelist accordingly).

Disclosure of Invention

According to an aspect of the present invention, there is provided a firewall white list updating and testing method, including: acquiring an updated white list file; automatically generating an updated white list library file code based on the white list file to produce an updated white list module; and automatically testing the code of the updated white list module to generate a test report.

Alternatively or additionally to the above, in the firewall white list updating and testing method according to an embodiment of the present invention, the automatic test is performed using a forward test case and a reverse test case.

Alternatively or additionally to the above solution, in the method for updating and testing a white list of a firewall according to an embodiment of the present invention, the performing a test using the forward test case and the reverse test case includes: and traversing the forward test case and the reverse test case to perform automatic test.

Alternatively or additionally to the above solution, the method for updating and testing a white list of a firewall according to an embodiment of the present invention further includes: modifying code of the updated whitelist module based on the test report.

Alternatively or additionally to the above, in the firewall white list updating and testing method according to an embodiment of the present invention, the updated white list file includes an updated white list rule table and an updated requirement specification.

Alternatively or additionally to the above solution, the method for updating and testing a firewall white list according to an embodiment of the present invention further includes: the differences between the updated white list file and the original white list file are compared to generate a change point list.

According to another aspect of the present invention, there is provided a firewall white list updating and testing apparatus, comprising: a file receiving device configured to obtain an updated white list file; an automatic updating means configured to automatically generate updated white list library file codes based on the white list files to produce updated white list modules; and automatic testing means configured to automatically test the code of the updated white list module to generate a test report.

Alternatively or additionally to the above, in the firewall white list updating and testing device according to an embodiment of the present invention, the automatic testing apparatus is further configured to execute automatic testing by using the forward test case and the reverse test case.

Alternatively or additionally to the above, in the firewall white list updating and testing apparatus according to an embodiment of the present invention, the automatic testing device is further configured to traverse the forward test case and the reverse test case to perform the automatic test.

Alternatively or additionally to the above solution, the firewall white list updating and testing apparatus according to an embodiment of the present invention further includes: code modification means configured to modify code of the updated whitelist module in accordance with the test report.

Alternatively or additionally to the above, in the firewall white list updating and testing apparatus according to an embodiment of the present invention, the updated white list file includes the updated white list rule table and the updated requirement specification.

Alternatively or additionally to the above solution, the firewall white list updating and testing apparatus according to an embodiment of the present invention further includes: a demand analysis device configured to compare differences of the updated white list file and the original white list file to generate a change point list.

According to yet another aspect of the present invention, there is provided a computer readable storage medium having stored thereon program instructions executable by a processor, the program instructions when executed by the processor performing a method according to an aspect of the present invention.

According to a further aspect of the invention, there is provided a vehicle comprising an apparatus according to one aspect of the invention.

According to the vehicle firewall updating and testing method, device, storage medium and vehicle, optimization can be performed on a system level, so that the working efficiency is improved, the time for code development and maintenance is shortened, the stability and reliability of software are improved, and the risk that errors are easily caused when codes are updated manually is reduced.

Drawings

The above and/or other aspects and advantages of the present invention will become more apparent and more readily appreciated from the following description of the various aspects taken in conjunction with the accompanying drawings, in which like or similar elements are designated with like reference numerals. In the drawings:

FIG. 1 is a schematic diagram of a firewall configuration for a vehicle according to an embodiment of the present invention; and

FIG. 2 is a schematic flow chart diagram of a vehicle firewall updating and testing method according to an embodiment of the invention; and

FIG. 3 is a schematic block diagram of a vehicle firewall updating and testing apparatus according to an embodiment of the present invention.

Detailed Description

In this specification, the invention is described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown. This invention may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. The embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

Words such as "comprising" and "comprises" mean that, in addition to having elements or steps which are directly and unequivocally stated in the description and the claims, the solution of the invention does not exclude other elements or steps which are not directly or unequivocally stated. Terms such as "first" and "second" do not denote an order of the elements in time, space, size, etc., but rather are used to distinguish one element from another.

The present invention is described below with reference to flowchart illustrations, block diagrams, and/or flow diagrams of methods and systems according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block and/or flow diagram block or blocks. It should also be noted that, in some alternative implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Where applicable, the various embodiments provided by the present disclosure may be implemented using hardware, software, or a combination of hardware and software. Additionally, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the scope of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. Further, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

Referring now to fig. 1, fig. 1 is a schematic diagram of a vehicle firewall arrangement according to an embodiment of the invention. In FIG. 1, BCM (Body Control Module) is a vehicle Body Control Module, IPC (Instrument Panel Cluster) is an Instrument Panel Cluster of an automobile, EBCM (Electronic Brake Control Module) is an Electronic Brake Control Module, NGI system (Next Generation information) is a Next-Generation Infotainment system, DLC (Diagnostic Link Connector) is a Diagnostic Link Connector, D-CAN is a Diagnostic CAN, I-CAN is an Infotainment CAN, P-CAN is a power CAN, and E-CAN is a chassis CAN.

In the case of a filtering firewall, the firewall mainly works according to white list or black list files, for example, to make security judgment on the CAN messages. In one embodiment, the white list may consist of IDs of CAN messages in each CAN message that are considered safe, trusted, or require passage through a firewall. In the case of using such a white list, CAN messages having CAN message IDs other than the white list cannot pass through the firewall. In contrast, in the case of using the blacklist, the CAN messages outside the blacklist CAN pass through the firewall. In another embodiment, the white list may consist of certain characteristics of the CAN message, which may include, for example, one or more of the following: from a certain IP address, from an external connection request, from a certain network, originating locally, using a certain protocol, etc. Under the condition of using the white list, the work according to the white list mainly comprises the steps of carrying out certain judgment on the received CAN communication message according to the preset forwarding condition so as to determine whether the CAN message CAN be forwarded (namely, through a firewall). For example, whether to forward a message from the E-CAN in fig. 1 to the D-CAN and/or I-CAN may be determined based on whether a CAN message comes from the IP address of a. In one embodiment, the logic associated with CAN data reception is implemented in the CAN driver module.

Conventionally, the size of the white list is usually huge because the ID messages of all CAN buses in each CAN bus communication are detected, and multiple regular judgment processing and illegal message filtering are required to be performed on each message. Meanwhile, with the increase of the message types, the scale of the white list tends to be further expanded. In the past development process, the white list rule table is firstly issued by a system architect, and then a person in charge of the white list module updates the code of the white list module in a manual mode (the updated content depends on the files of the white list library). Manually updating the white list library file requires updating the members of the CAN bus ID structure body in the library line by line according to the white list rule table. Generally, one CAN bus may include 2048 CAN standard frame structure members and N CAN extended frame structure members. Besides updating the structural member of the white list library, the structural member of the corresponding rule library also needs to be updated, namely, an input test message is needed to be verified when the developed white list module is tested. The conventional development method of the white list module software is time-consuming and error-prone, so that a set of tool software capable of automatically generating and detecting white list library codes (white list module codes) needs to be developed.

Referring now to fig. 2, fig. 2 is a schematic flow chart diagram of a vehicle firewall updating and testing method 100 according to an embodiment of the invention.

In step S101, an updated white list file is first acquired. Typically, a new white list file is published after a white list update, including an updated white list rule table, updated requirements specifications, and firewall rule files. In one embodiment, the content of the white list is an identification of objects that may be allowed to pass through the firewall, a characteristic used to determine whether an object may pass through the firewall, or the like. For example, the content of the whitelist may include, for example, ID1= a, ID2= B, ID3= C; and/or the object is from an IP address M, transmitted using a protocol N, etc. Accordingly, the white list rule table may be a file that specifies how to work according to the white list. For example, the whitelist rule table may be a table that allows objects identified in a whitelist ID range to pass through, objects that allow a source IP address in a whitelist IP address range to pass through, or objects that use a protocol in a whitelist protocol range to pass through. The white list rules table may also incorporate several of the above rules, for example, objects identified in the white list ID range and having a source IP address in the white list IP address range may be allowed to pass through. The requirement specification is, for example, "it is necessary to pass an object whose ID is a". The firewall rule file performs a protection operation according to the first white list rule table and the second white list rule table, for example.

Optionally, in step S102, the requirement is analyzed according to the requirement specification. And analyzing the difference between the updated white list file and the original white list file, sorting the code structure design and forming a change point list. For example, if the updated requirement specification includes an object with ID4= D in a passable object ID range (i.e., the change point list includes the object ID with the new ID4= D), the code of the white list rule table should be changed accordingly, and the logic for determining ID4= D is written into the white list rule table.

In step S103, the whitelist library code is updated, including automatically generating an updated whitelist library code. Wherein automatically generating updated white list library code comprises: the method includes automatically generating white list module library file codes and rule codes (e.g., automatically converting an imported white list rule table into white list library codes) according to a white list rule table (e.g., imported by one key), setting the white list module file codes and the rule codes in a white list module (e.g., a source file corresponding to the white list module) to generate updated white list modules, and setting automatically generated related rule macro definitions and structure types in corresponding header files. Optionally, a white list library may be automatically integrated for subsequent automated testing procedures. By automatically updating the white list module, the working efficiency is improved, and the precious development time is shortened.

In step S104, the generated white list module code is automatically tested. Specifically, the white list module codes are converted into dynamic library files and loaded into an automatic white list library test tool, and a test case template (comprising a forward test case and a reverse test case) is led into a CANOE (automobile bus simulation development software) test tool. And starting automatic testing, traversing the forward test case and the reverse test case by the automatic white list library testing tool according to the automatically generated and integrated white list library file to test the white list module by using the forward test case and the reverse test case, thereby quickly completing the coverage test of the complete rule, and automatically outputting a test report after the test is finished. Based on the test report, problems in the code of the updated whitelist module may be modified. The test is repeated until all test cases have passed. Through automatic testing, the human cost is reduced. By using the bidirectional test case for testing, the coverage rate of reverse test contents is improved, the universality is good, and the stability and the reliability of software can be improved. By reducing the time for code development and maintenance and reducing the risk of error-susceptibility to manually updating code.

After step S104, development process documentation may also be performed. And (3) organizing a test case report according to the test result, modifying the software release description and related archived files, making module integrated files, and finally uploading all archived files to an RTC (cooperative software delivery environment of IBM corporation) server and issuing updated white list module codes.

According to the method 100 for updating and testing the white list of the vehicle firewall, the white list library codes can be quickly and automatically generated under the condition of one-key import of the requirements, and the codes of the corresponding white list modules can be automatically tested.

Referring now to fig. 3, fig. 3 is a schematic block diagram of a vehicle firewall updating and testing apparatus 200 according to an embodiment of the invention.

The vehicle firewall updating and testing apparatus 200 may include a file receiving device 210 configured to obtain an updated white list file. Typically, a new white list file is published after a white list update, including an updated white list rule table, updated requirements specifications, and firewall rule files. In one embodiment, the content of the white list is an identification of objects that may be allowed to pass through the firewall, a characteristic used to determine whether an object may pass through the firewall, and the like. For example, the content of the whitelist may include, for example, ID1= a, ID2= B, ID3= C; and/or the object is from an IP address M, transmitted using a protocol N, etc. Accordingly, the white list rule table may be a file that specifies how to work according to the white list. For example, the whitelist rule table may be a table that allows objects identified in a whitelist ID range to pass through, objects that allow a source IP address in a whitelist IP address range to pass through, or objects that use a protocol in a whitelist protocol range to pass through. The white list rules table may also incorporate several of the above rules, for example, objects identified in the white list ID range and having a source IP address in the white list IP address range may be allowed to pass through. The requirement specification is, for example, "it is necessary to pass an object whose ID is a". The firewall rule file performs protection operation according to the first white list rule table and the second white list rule table, for example.

Optionally, the vehicle firewall updating and testing apparatus 200 may further include a requirement analysis device 220, which may be configured to analyze the requirement according to the requirement specification. The requirement analysis device 220 may analyze the difference between the updated white list file and the original white list file, arrange the code structure design, and form a change point list. For example, if the updated requirement specification includes an object with ID4= D in a passable object ID range (i.e., the change point list includes the object ID with the new ID4= D), the code of the white list rule table should be changed accordingly, and the logic for determining ID4= D is written into the white list rule table.

The vehicle firewall updating and testing apparatus 200 may further include an automatic updating means 230 for updating the whitelist library code, including automatically generating an updated whitelist library code. The automatic generation of the updated white list library code by the automatic updating device 230 includes: the method includes automatically generating white list module library file codes and rule codes (e.g., automatically converting an imported white list rule table into white list library codes) according to a white list rule table (e.g., imported by one key), setting the white list module file codes and the rule codes in a white list module (e.g., a source file corresponding to the white list module) to generate updated white list modules, and setting automatically generated related rule macro definitions and structure types in corresponding header files. Optionally, the automatic updating apparatus 230 may automatically integrate the published white list library for subsequent automated testing processes. By automatically updating the white list module, the working efficiency is improved, and the precious development time is shortened.

The vehicle firewall updating and testing apparatus 200 may further include an automatic testing device 240 for automatically testing the generated white list module code. Specifically, the automatic test apparatus 240 may be configured to convert the white list module code into a dynamic library file, load the dynamic library file into the white list library automatic test tool, and import a test case template (including a forward test case and a reverse test case) into a CANOE (a kind of automobile bus simulation development software) test tool. And starting automatic testing, wherein according to the white list library file automatically generated and integrated, the automatic testing device 240 can traverse the forward test case and the reverse test case by using the white list library automatic testing tool so as to test the white list module by using the forward test case and the reverse test case, thereby quickly completing the coverage test of the full rule and automatically outputting a test report after the test is finished.

According to the test report, problems existing in the code of the updated whitelist module may be modified by a code modification means (not shown in fig. 3). The test is repeated until all test cases have passed. Through automatic testing, the human cost is reduced. The bidirectional test case is used for testing, so that the coverage rate of reverse test contents is improved, the universality is good, and the stability and the reliability of software can be improved. By reducing the time for code development and maintenance and reducing the risk of error-susceptibility to manually updating code.

Development process documentation may also be conducted through vehicle firewall updates and other components of the testing device 200 after the automatic testing apparatus 240 completes testing. And (3) organizing a test case report according to the test result, modifying the software release description and related archived files, making module integrated files, and finally uploading all archived files to an RTC (cooperative software delivery environment of IBM corporation) server and issuing updated white list module codes.

The apparatus 200 for updating and testing the white list of the firewall of the vehicle according to the present invention can rapidly and automatically generate the code of the white list library and automatically test the code of the corresponding white list module under the condition of one-key importing of the requirement.

According to yet another aspect of the invention, a computer readable storage medium is provided having program instructions stored thereon that are executable by a processor. The program instructions, when executed by a processor, may be configured to perform a method according to an aspect of the invention.

According to yet another aspect of the present invention, a vehicle is provided. The vehicle comprising an apparatus according to an aspect of the invention.

The foregoing disclosure is not intended to limit the disclosure to the precise forms or particular fields of use disclosed. Accordingly, it is contemplated that various alternative embodiments and/or modifications of the disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, it will be recognized by those of ordinary skill in the art that changes in form and detail may be made therein without departing from the scope of the present disclosure. Accordingly, the disclosure is limited only by the claims.

Claims

1. A firewall white list updating and testing method comprises the following steps:

acquiring an updated white list file;

automatically generating an updated white list library file code based on the white list file to produce an updated white list module; and

automatically testing the code of the updated white list module to generate a test report.

2. The method of claim 1, wherein the automatic testing is performed using forward test cases and reverse test cases.

3. The method of claim 2, wherein performing testing using the forward test case and the reverse test case comprises:

and traversing the forward test case and the reverse test case to perform the automatic test.

4. The method of claim 1, further comprising:

code for modifying the updated whitelist module based on the test report.

5. The method of claim 1, wherein the updated whitelist file includes an updated whitelist rule table and an updated requirements specification.

6. The method of claim 1, further comprising:

the differences between the updated white list file and the original white list file are compared to generate a change point list.

7. A firewall whitelist updating and testing device, comprising:

a file receiving device configured to obtain an updated white list file;

an automatic updating device configured to automatically generate an updated white list library file code based on the white list file to produce an updated white list module; and

an automatic test device configured to automatically test code of the updated whitelist module to generate a test report.

8. The apparatus of claim 7, wherein the automatic test device is further configured to: the automatic testing is performed using the forward test case and the reverse test case.

9. The apparatus of claim 8, wherein the automatic test device is further configured to: and traversing the forward test case and the reverse test case to execute the automatic test.

10. The apparatus of claim 7, further comprising:

code modifying means configured to modify code of the updated whitelist module in accordance with the test report.

11. The apparatus of claim 7, wherein the updated whitelist file includes an updated whitelist rule table and an updated requirements specification.

12. The apparatus of claim 7, further comprising:

a demand analysis device configured to compare differences of the updated white list file and the original white list file to generate a change point list.

13. A computer readable storage medium having stored thereon program instructions executable by a processor, the program instructions when executed by the processor performing the method of any of claims 1-6.

14. A vehicle comprising an apparatus according to any one of claims 7-12.