Method for evaluating security of in-vehicle network

Abstract

According to some embodiments of the present disclosure, a method for evaluating the security of an in-vehicle network performed by a computing device including at least one processor is disclosed. The method for evaluating the security of an in-vehicle network may comprise the steps of: constructing a fuzzing framework for performing a security evaluation method; and performing the security evaluation method by using the constructed framework.

Description

A method for assessing the security of in-vehicle networks

[0001] The present disclosure relates to a method for scheduling a battery, and more particularly, to a method for scheduling a battery for operation of a mobile device.

[0002] Research on this disclosure was supported by the Ministry of Trade, Industry and Energy and the Korea Industrial Technology Evaluation and Planning Institute.

[0003] Assignment ID: 1415181535

[0004] Assignment Number: 20022229

[0005] Ministry Name: Ministry of Trade, Industry and Energy

[0006] Project Management (Professional) Agency Name: Korea Industrial Technology Evaluation and Planning Institute

[0007] Research Project Name: Autonomous Driving Technology Development Innovation Project

[0008] Research Project Name: Development of Security Evaluation Technology for Internal Networks and Wireless Software Updates in Autonomous Driving Systems

[0009] Contribution rate: 1 / 1

[0010] Project execution organization name: Ahop Co., Ltd.

[0011] Research period: June 1, 2022 - December 31, 2025

[0012] Modern society's transportation environment is gradually evolving into an intelligent transportation system. In line with this evolution, intelligent vehicles equipped with features such as infotainment, safety, road assistance, and telematics are being released.

[0013] Intelligent vehicles have significantly increased the number of electronic control units (ECUs) and electrical and electronic components due to the introduction of various in-vehicle functions. ECUs are installed throughout the vehicle and perform sensing and computation related to vehicle control. These ECUs can include various types of EGN (Engine) ECUs, ABS (Anti-lock Braking System) ECUs, multimedia ECUs, transmission ECUs, and safety-related ECUs. A single vehicle can contain anywhere from 60 to 100 ECUs.

[0014] ECUs have a hierarchical structure, performing unique functions while also performing cooperative control with other ECUs. For communication between ECUs, an in-vehicle network (IVN) can be used. Examples of in-vehicle networks include the Controller Area Network (CAN), CAN with Flexible Data Rate (CAN FD), and Ethernet.

[0015] Meanwhile, as vehicle software becomes more complex, the functionality of ECUs is rapidly evolving. ECUs are frequently updated to new versions to add new features, improve performance, or detect vehicle abnormalities. ECU updates can be performed wirelessly or via wired communication between the vehicle's internal network and external networks. Communication between the vehicle's internal network and external networks is expected to become more frequent as autonomous vehicle technology advances.

[0016] Although it may be semi-essential for the in-vehicle network to communicate with an external network to improve the performance of the vehicle, this may increase the security threat to the in-vehicle network or ECU.

[0017] The present disclosure is conceived in response to the aforementioned background technology and aims to provide a method for evaluating the security of an in-vehicle network.

[0018] The technical problems of the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

[0019] According to one embodiment of the present disclosure for solving the above-described problem, a method for evaluating the security of an in-vehicle network performed by a computing device including at least one processor is disclosed. The method for evaluating the security of the in-vehicle network includes the steps of: constructing a fuzzing framework for performing the security evaluation method; and performing the security evaluation method using the constructed framework; wherein the security evaluation method may include the steps of: extracting a message list from a CAN DB file; generating at least one test case using a message included in the extracted message list; injecting a first test case among the at least one test case into a target control device constituting the in-vehicle network; performing an analysis on whether the target control device is abnormal due to the injection of the first test case; and determining whether to inject a second test case among the at least one test case based on whether the target control device is abnormal.

[0020] In addition, the step of building a fuzzing framework for performing the security evaluation method may include the step of building a first requirement for the scope of the fuzzer; the step of building a second requirement for the at least one test case; the step of building a third requirement for the protocol of the in-vehicle network; the step of building a fourth requirement for logging of the in-vehicle network; the step of building a fifth requirement for replay of an attack method for a target control device; and the step of building a sixth requirement for a result report.

[0021] In addition, the first requirement may include at least one of the following requirements: a 1-1 requirement for generating a test case for a preset message in the CAN DB file, a 1-2 requirement for performing a fuzzing test for a UDS (Unified Diagnostic Services) protocol message, a 1-3 requirement for performing fuzzing through randomization for data within a specified range, and a 1-4 requirement for performing fuzzing through randomization for the entire CAN message.

[0022] Additionally, the second requirement may include at least one of the second requirement, which allows test cases to be generated based on a structure standard set by the user, and the second requirement, which allows modifications to the generated test cases.

[0023] Additionally, the third requirement may include at least one of the third-1 requirement for a protocol for supporting CAN communication and CAN-FD communication and the third-2 requirement for a protocol for supporting Ethernet.

[0024] Additionally, the fourth requirement may include at least one of the following requirements: requirement 4-1 for logging all CAN messages within CAN communication, requirement 4-2 for logging all messages on connected CAN communication, and requirement 4-3 for outputting and extracting log files.

[0025] In addition, the fifth requirement may include at least one of the following requirements: requirement 5-1, which enables a retransmission attack using the message when a vulnerability of the target control device is discovered as a result of an attack on the target control device; requirement 5-2, which enables automatic replay; and requirement 5-3, which enables manual replay.

[0026] Additionally, the sixth requirement may include at least one of the sixth requirement for providing a report on discovered vulnerabilities and the sixth requirement for extracting the final discovered vulnerability results to a local file.

[0027] In addition, the step of generating at least one test case using a message included in the extracted message list includes the step of generating the at least one test case according to a fuzzing algorithm; and the fuzzing algorithm may include at least one of a dump fuzzing algorithm, a generation-based fuzzing algorithm, a mutation-based fuzzing algorithm, an evolutionary fuzzing algorithm, and a stateful fuzzing algorithm.

[0028] In addition, the step of analyzing whether there is an abnormality in the target control device according to the injection of the first test case may include the steps of: transmitting a status confirmation message to the target control device; determining the first test case as a risk candidate if a response to the status confirmation message is not received; restarting the target control device; retransmitting the first test case to the restarted target control device; transmitting the status confirmation message to the restarted target control device; and determining the first test case as a vulnerable case if a response to the status confirmation message is not received.

[0029] In addition, a computing device for evaluating the security of an in-vehicle network includes a control unit configured to construct a fuzzing framework for performing a security evaluation method and to perform the security evaluation method using the constructed framework; wherein the security evaluation method may include: a step of extracting a message list from a CAN DB file; a step of generating at least one test case using a message included in the extracted message list; a step of injecting a first test case among the at least one test case into a target control device constituting the in-vehicle network; a step of performing an analysis on whether or not the target control device is abnormal due to the injection of the first test case; and a step of determining whether or not to inject a second test case among the at least one test case based on whether or not the target control device is abnormal.

[0030] The technical solutions obtainable in the present disclosure are not limited to the solutions mentioned above, and other solutions not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the description below.

[0031] According to some embodiments of the present disclosure, a method for evaluating the security of an in-vehicle network can be provided so that a security system that is safe from threats to the vehicle system can be constructed.

[0032] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the description below.

[0033] Various aspects are now described with reference to the drawings, wherein like reference numerals are used to refer to similar elements generally. In the following examples, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of one or more aspects. However, it will be apparent that such aspects may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate the description of one or more aspects.

[0034] FIG. 1 is a block diagram illustrating an example of a computing device according to some embodiments of the present disclosure.

[0035] FIG. 2 is a flowchart illustrating an example of a method for evaluating the security of an in-vehicle network by a computing device according to some embodiments of the present disclosure.

[0036] FIG. 3 is a flowchart illustrating an example of a method for a computing device to build a fuzzing framework according to some embodiments of the present disclosure.

[0037] FIG. 4 is a flowchart illustrating an example of a method for performing a security evaluation method using a fuzzing framework built on a computing device according to some embodiments of the present disclosure.

[0038] FIG. 5 is a flowchart illustrating an example of a method by which a computing device performs an analysis of whether a target control device is abnormal, according to some embodiments of the present disclosure.

[0039] The present invention is susceptible to various modifications and embodiments. Specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the present invention. Throughout the description of each drawing, similar reference numerals have been used to designate similar components.

[0040] Terms such as "first," "second," "A," and "B" may be used to describe various components, but the components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the "second component," and similarly, the second component may also be referred to as the "first component." The term "and / or" includes a combination of a plurality of related items described herein or any of a plurality of related items described herein.

[0041] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0042] The terminology used in this application is only used to describe specific embodiments and is not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, it should be understood that the terms "comprise" or "have" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0043] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and will not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0044] In the present disclosure, a computing device can evaluate the security of an in-vehicle network by performing a security evaluation method. To perform the security evaluation method, the computing device can build a fuzzing framework. Here, fuzzing can be a method for testing software vulnerabilities. Furthermore, the fuzzing framework can be understood as a tool built to test software vulnerabilities. The computing device can evaluate the security of an in-vehicle network by performing the security evaluation method using the built framework. Hereinafter, a method for a computing device to evaluate the security of an in-vehicle network will be described with reference to FIGS. 1 to 4.

[0045] FIG. 1 is a block diagram illustrating an example of a computing device according to some embodiments of the present disclosure.

[0046] Referring to FIG. 1, a computing device (100) may include a control unit (110), a storage unit (120), and a communication unit (130). However, the above-described components are not essential for implementing the computing device (100), and thus the computing device (100) may have more or fewer components than the components listed above.

[0047] The computing device (100) may include any type of computer system or computer device, such as, for example, a microprocessor, a mainframe computer, a digital processor, a portable device, or a device controller.

[0048] A computing device (100) may achieve desired system performance by utilizing a combination of typical computer hardware (e.g., devices that may include a computer processor, memory, storage, input devices and output devices, and other components of conventional computing devices; electronic communication devices such as routers, switches, etc.; electronic information storage systems such as network-attached storage (NAS) and storage area networks (SAN)) and computer software (i.e., instructions that cause the computing device to function in a particular manner).

[0049] The control unit (110) can typically process the overall operation of the computing device (100). The control unit (110) can process signals, data, information, etc. input or output through components of the computing device (100) or run application programs stored in the storage unit (120), thereby providing or processing appropriate information or functions to the user.

[0050] The control unit (110) may be composed of one or more cores and may include a processor for data analysis, such as a central processing unit (CPU), a general purpose graphics processing unit (GPGPU), or a tensor processing unit (TPU).

[0051] In the present disclosure, the control unit (110) can build a fuzzing framework to perform a security evaluation method.

[0052] For example, the control unit (110) can build a fuzzing framework to build requirements for the scope of the fuzzer, requirements for test cases, requirements for protocols of the in-vehicle network, requirements for logging of the in-vehicle network, requirements for replay of attack methods for the target control device, and requirements for result reports.

[0053] Below, an example of a method for the control unit (110) to build a fuzzing framework is described through FIG. 2.

[0054] The storage unit (120) may include memory and / or a permanent storage medium. The memory may include at least one type of storage medium among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, and an optical disk.

[0055] In the present disclosure, the storage unit (120) may store a database constructed by the control unit (110). The control unit (110) may store, view, or modify test models, fuzzing algorithms, known vulnerabilities, attack scenarios, security threats, and vulnerability information for generating test cases constructed as a database.

[0056] The communication unit (130) may include one or more modules that enable communication between the computing device (100) and the communication system, between the computing device (100) and a vehicle, or between the computing device (100) and a network.

[0057] Below, a specific example of a computing device (100) evaluating the security of an in-vehicle network is described.

[0058] FIG. 2 is a flowchart illustrating an example of a method for evaluating the security of an in-vehicle network performed by a computing device according to some embodiments of the present disclosure. FIG. 3 is a flowchart illustrating an example of a method for building a fuzzing framework by a computing device according to some embodiments of the present disclosure.

[0059] Referring to FIG. 2, the control unit (110) of the computing device (100) can construct a fuzzing framework for performing a security assessment method (S110). Here, fuzzing may be a method for testing software vulnerabilities. Furthermore, the fuzzing framework can be understood as a tool constructed to test software vulnerabilities.

[0060] Depending on the level of understanding of the software being analyzed, fuzzing can be classified into black box testing techniques, gray box testing techniques, and white box testing techniques.

[0061] Black box testing techniques can be performed without prior knowledge of the source code, internal structure, or internal operations of the software being analyzed. When using black box testing techniques, the tester only has knowledge of the program's input and output values, and can perform tests based on exceptions observed outside the program. Black box testing techniques can be performed by general users without specialized knowledge, and test case creation time is relatively short compared to white box testing techniques, but code coverage may be low. Black box testing techniques include equivalence partitioning, boundary value analysis, cause-effect graphs, orthogonal array testing, and state transition testing.

[0062] Gray-box testing techniques can be performed with limited knowledge of the internal workings of the software being analyzed. When utilizing gray-box testing techniques, testers must have some prior knowledge of the program's internal data structures and algorithms. Gray-box testing techniques can offer the advantages of both black-box and white-box testing techniques, but generally offer lower code coverage than white-box testing techniques. Gray-box testing techniques include orthogonal array testing, matrix testing, regression testing, and pattern testing.

[0063] White-box testing techniques can be performed based on prior knowledge of the internal logic and structure of the software being analyzed. When using white-box testing techniques, the tester must have all necessary knowledge of the program's source code and may need a certain level of program expertise to perform the test. White-box testing techniques can find errors in program implementation or hidden code that are difficult to find with black-box testing techniques. White-box testing techniques provide high code coverage because they require knowledge of the source code, but test case generation can take relatively longer than black-box testing techniques. White-box testing techniques include control flow testing, branch testing, basis path testing, data flow testing, and loop testing.

[0064] The control unit (110) can construct a fuzzing framework to include at least one requirement. Here, the requirement can be understood as defining the performance that the fuzzing framework must satisfy. For convenience of explanation, reference may be made to FIG. 3.

[0065] Referring to FIG. 3, the control unit (110) can establish a first requirement regarding the scope of a fuzzer (S111). Fuzzing is a method of injecting semi-random data into target software and can be understood as a concept identical to or similar to fuzzing. The scope of a fuzzer can be understood as the range of data generated. The scope of a fuzzer can also be understood as the range of messages for generating test cases. By establishing the first requirement, the control unit (110) can determine the scope of a fuzzer.

[0066] The first requirement may include at least one of requirements 1-1 to 1-4.

[0067] Requirement 1-1 may be a requirement for generating test cases for preset messages within a CAN DB file (DBC file). The CAN DB file may be a network database file used in CAN communication. The CAN DB file may be obtained from a manufacturer and pre-stored in a storage unit (120). The control unit (110) may construct Requirement 1-1 to perform a security evaluation method by reading the CAN DB file and generating test cases for preset messages within the database.

[0068] Requirements 1-2 may be requirements for performing a fuzzing test on a Unified Diagnostic Services (UDS) protocol message. The UDS protocol may be a diagnostic communication protocol used for diagnosing, testing, or repairing an in-vehicle control unit (ECU). The UDS protocol message may be a message transmitted to perform the above-described operation. The control unit (110) may establish requirements 1-2 to perform a security evaluation method on a UDS protocol message.

[0069] Requirement 1-3 may be a requirement to perform fuzzing through randomization of data within a specified range. The control unit (110) may establish requirement 1-3 so that a security evaluation method is implemented in which fuzzing is performed through randomization of data within a specified range.

[0070] Requirement 1-4 may be a requirement to perform fuzzing through randomization of the entire CAN message. The control unit (110) may establish requirement 1-4 so that a security evaluation method is implemented in which fuzzing is performed through randomization of the entire CAN message.

[0071] The control unit (110) can establish a second requirement for at least one test case (S112). The test case may be an attack to be injected into the target control device.

[0072] The second requirement may include at least one of the second-1 requirement and the second-2 requirement.

[0073] Requirement 2-1 may be a requirement that test cases be generated based on a user-defined structure. The structure may be understood as the structure of a test case. When performing a security assessment method, the control unit (110) may establish Requirement 2-1 so that test cases are generated based on the user-defined structure.

[0074] Requirement 2-2 may be a requirement that allows modifications to the generated test cases. The control unit (110) may establish requirement 2-2 to allow modifications to the generated test cases.

[0075] The control unit (110) can establish a third requirement for the protocol of the in-vehicle network (S113). The protocol of the in-vehicle network can be understood as a communication protocol.

[0076] The third requirement may include at least one of requirements 3-1 and 3-2.

[0077] Requirement 3-1 may be a requirement for a protocol supporting CAN communication and CAN-FD communication. When performing a security evaluation method, the control unit (110) may establish Requirement 3-1 so that the security evaluation method can be performed through a protocol supporting CAN communication and CAN-FD communication.

[0078] Requirement 3-2 may be a requirement for a protocol for Ethernet support. When performing a security evaluation method, the control unit (110) may establish Requirement 3-2 so that the security evaluation method can be performed via a protocol for Ethernet support.

[0079] The control unit (110) can establish a fourth requirement for logging of the vehicle's internal network (S114). Logging may be an operation of recording a log, which is system operation information.

[0080] The fourth requirement may include at least one of requirements 4-1 to 4-3.

[0081] Requirement 4-1 may be a requirement for logging all CAN messages within CAN communication. When performing a security evaluation method, the control unit (110) may establish Requirement 4-1 so that logging is performed for all CAN messages within CAN communication.

[0082] Requirement 4-2 may be a requirement for logging all messages on connected CAN communication. When performing a security evaluation method, the control unit (110) may establish requirement 4-2 so that logging of all messages on connected CAN communication is performed.

[0083] Requirement 4-3 may be a requirement for outputting and extracting log files. When performing a security evaluation method, the control unit (110) may establish requirement 4-2 so that outputting and extracting log files are performed.

[0084] The control unit (110) can establish a fifth requirement for replay of an attack method against a target control device (S115).

[0085] Requirement 5 may include at least one of Requirements 5-1 to 5-3.

[0086] Requirement 5-1 may be a requirement that enables a replay attack using the corresponding message when a vulnerability in the target control device is discovered as a result of an attack on the target control device. The control unit (110) may establish Requirement 5-1 so that a replay attack using the corresponding message is enabled when a vulnerability in the target control device is discovered as a result of an attack on the target control device through the performance of a security assessment method.

[0087] Requirement 5-2 may be a requirement for automatic replay. The control unit (110) may establish Requirement 5-2 so that automatic replay is performed when a vulnerability in the target control device is discovered as a result of an attack on the target control device by performing a security assessment method.

[0088] Requirement 5-3 may be a requirement for manual replay. The control unit (110) may establish Requirement 5-3 to allow manual replay if a vulnerability in the target control device is discovered as a result of an attack on the target control device by performing a security assessment method.

[0089] The control unit (110) can establish the sixth requirement for the result report (S116).

[0090] Requirement 6 may include at least one of Requirement 6-1 and Requirement 6-2.

[0091] Requirement 6-1 may be a requirement for providing a report on discovered vulnerabilities. The control unit (110) may establish Requirement 6-1 so that, if a vulnerability is discovered through the performance of a security assessment method, a report on the discovered vulnerability is provided.

[0092] Requirement 6-2 may be a requirement for extracting the final discovered vulnerability results to a local file. The control unit (110) may configure Requirement 6-2 so that the final discovered vulnerability results are extracted to a local file.

[0093] The control unit (110) can perform a security evaluation method using the constructed framework (S120).

[0094] Specifically, by injecting an attack into an internal network where communication between control devices within a vehicle is performed using the framework built in the control unit (110), the security of the target control device or the internal network can be evaluated. Here, the target control device may be an Electronic Control Unit (ECU) or a Domain Control Unit (DCU).

[0095] According to one embodiment, the control unit (110) can establish a test environment that allows a plurality of control devices to perform communication within a virtual vehicle environment.

[0096] For example, if the target control device is a physical device, the control unit (110) can build a Hardware-in-the-Loop Simulation (HILS) test environment that allows the target control device to communicate within a virtual vehicle environment. The control unit (110) can control the target control device to implement communication in the built HILS test environment. For example, the computing device (100) can be connected to the target control device through a harness. The control unit (110) can control the target control device through the harness so that the target control device performs operations within the HILS test environment implemented by the computing device (100). According to one embodiment, the HILS test environment may be implemented through a separate simulator. In this case, the computing device (100) can be connected to the simulator in which the test environment is built through a harness, etc. The control unit (110) can control the simulator or the target control device through the harness so that the target control device performs operations within the HILS test environment implemented by the simulator.

[0097] As another example, if the target control device is a virtual device, the control unit (110) can build a Software-in-the-Loop Simulation (SILS) test environment that allows the target control device to communicate within a virtual vehicle environment. The control unit (110) can control the virtual target control device so that the target control device implements communication in the built SILS test environment. According to one embodiment, the SILS test environment may be implemented through a separate simulator. In this case, the computing device (100) can be connected to the simulator in which the test environment is built through a harness or the like. The control unit (110) can control the simulator or the target control device through the harness so that the target control device performs communication within the SILS test environment implemented by the simulator.

[0098] According to the above-described configuration, the computing device (100) can construct a fuzzing framework that satisfies the first through sixth requirements to perform a security assessment method. Furthermore, the computing device (100) can perform a security assessment method on a target control device using the constructed fuzzing framework. Accordingly, the reliability of the performed security assessment can be enhanced.

[0099] Below, an example of a method for performing a security evaluation method using a fuzzing framework built on a computing device is described.

[0100] FIG. 4 is a flowchart illustrating an example of a method for performing a security evaluation method using a fuzzing framework built on a computing device according to some embodiments of the present disclosure.

[0101] Referring to FIG. 4, the control unit (110) of the computing device (100) can extract a message list from a CAN DB file (S210).

[0102] Specifically, the control unit (110) can extract a message list from a CAN DB file through a fuzzing framework in which a first requirement for the scope of the fuzzer is established.

[0103] The control unit (110) can generate at least one test case using messages included in the extracted message list (S220). Here, the test case may be a case for attacking the target control device.

[0104] Specifically, the control unit (110) can generate at least one test case through a fuzzing framework in which a second requirement for at least one test case is constructed.

[0105] In one embodiment, the control unit (110) may generate at least one test case based on a fuzzing algorithm. The fuzzing algorithm may be an algorithm that inputs a large amount of data and generates an attack script that identifies the location of a vulnerability that causes a collision. The control unit (110) may use the generated attack script to generate at least one test case.

[0106] The fuzzing algorithm may include at least one of a dump fuzzing algorithm, a generation-based fuzzing algorithm, a mutation-based fuzzing algorithm, an evolutionary fuzzing algorithm, and a stateful fuzzing algorithm.

[0107] A dump fuzzing algorithm may be an algorithm that generates test cases without any information about the system. The control unit (110) may generate test cases using a dump fuzzing algorithm that randomly generates given input values. Here, the system or target system may refer to a target control device and an internal vehicle network.

[0108] A generation-based fuzzing algorithm may be an algorithm that generates test cases for a fuzzing target based on a script-based generation method. Here, the script-based generation method may be an algorithm that provides data information of a target for fuzzing testing in the form of a Python script and generates test cases based on this. A generation-based fuzzing algorithm may generate test cases based on format information about data input to a target system. A generation-based fuzzing algorithm may be an algorithm that extracts information about message structure, type, and internal fields of a message from a specification or RFC document, and generates test cases by adding abnormal data to a portion of a normal input format. The control unit (110) may generate test cases by adding abnormal data to a portion of a normal input format through a generation-based fuzzing algorithm.

[0109] A mutation-based fuzzing algorithm can be an algorithm that collects legitimate data input to a target system and utilizes it as a test case. A mutation-based fuzzing algorithm can be an algorithm that generates test cases by adding anomalous data to legitimate data collected from files or network traffic. The control unit (110) can generate test cases by adding anomalous data to legitimate data using a mutation-based fuzzing algorithm.

[0110] An incremental fuzzing algorithm may be an algorithm that provides fuzzing data to a target system and then determines the generation of the next fuzzing data based on the system's response. An incremental fuzzing algorithm may be an algorithm that assigns scores to performed test cases based on the target system's response to the fuzzing operation, and utilizes test cases with high scores to generate the next test case. The control unit (110) may provide fuzzing data to the target system through an incremental fuzzing algorithm and then determine the generation of the next fuzzing data based on the system's response.

[0111] A state-based fuzzing algorithm may be an algorithm that generates fuzzing data based on the state of the target system. If the target system has multiple states and each state processes input differently, the control unit (110) may generate test cases using the state-based fuzzing algorithm.

[0112] The control unit (110) can generate at least one test case using at least one algorithm among a dump fuzzing algorithm, a generation-based fuzzing algorithm, a mutation-based fuzzing algorithm, an incremental fuzzing algorithm, and a state-based fuzzing algorithm, depending on the type of the vehicle internal network or target control device.

[0113] The control unit (110) can inject the first test case among at least one test case into a target control device constituting an in-vehicle network (S230). Alternatively, the control unit (110) can also inject the first test case into the in-vehicle network.

[0114] Specifically, the control unit (110) can inject the first test case into the target control device through a fuzzing framework in which the third requirement for the protocol of the vehicle internal network is established.

[0115] The control unit (110) can perform an analysis on whether there is an abnormality in the target control device according to the injection of the first test case (S240).

[0116] Specifically, the control unit (110) can inject the first test case into the target control device. The control unit (110) can transmit a status confirmation message to the target control device. Furthermore, the control unit (110) can determine whether the target control device is operating abnormally based on whether a response to the status confirmation message is received. An example of a method by which the control unit (110) analyzes whether the target control device is operating abnormally following the injection of the first test case is described below with reference to FIG. 5.

[0117] The control unit (110) can determine whether to inject the second test case among at least one test case based on whether the target control device is abnormal (S250).

[0118] For example, if the control unit (110) determines that an abnormality has occurred in the target control device, the control unit (110) may determine the first test case as a vulnerable case. In addition, the control unit (110) may not inject the second test case.

[0119] For another example, the control unit (110) may inject a second test case if it is determined that no abnormality has occurred in the target control device.

[0120] After injection of the first test case or after injection of the second test case, the control unit (110) can generate a result report according to the injection of the test case through the fuzzing framework in which the sixth requirement for the result report is established.

[0121] Additionally, the control unit (110) can output a log file according to the injection of a test case through a fuzzing framework in which the fourth requirement for logging of the vehicle internal network is established.

[0122] According to the above-described configuration, the computing device (100) can perform a security assessment method using a framework built to satisfy multiple requirements. Accordingly, the reliability of the security assessment method can be increased, and furthermore, test records can be preserved intact.

[0123] Meanwhile, according to some embodiments of the present disclosure, the computing device (100) can perform an analysis of whether a target control device is abnormal due to the injection of the first test case. Hereinafter, an example of a method by which the computing device (100) according to the present disclosure performs an analysis of whether a target control device is abnormal will be described with reference to FIG. 5.

[0124] FIG. 5 is a flowchart illustrating an example of a method by which a computing device performs an analysis of whether a target control device is abnormal, according to some embodiments of the present disclosure.

[0125] Referring to FIG. 5, the control unit (110) of the computing device (100) can transmit a status confirmation message to the target control device (S241). Here, the status confirmation message may be a message requesting a response from the target control device.

[0126] If no response to the status confirmation message is received (S242, No), the control unit (110) may determine the first test case as a risk candidate (S243). The control unit (110) may store the first test case in a database in the storage unit (120).

[0127] If a response to the status confirmation message is received (S242, Yes), the control unit (110) may not determine the first test case as a risk candidate.

[0128] The control unit (110) can restart the target control device (S244). The control unit (110) can retransmit the first test case to the restarted target control device (S245). In addition, the control unit (110) can transmit a status confirmation message to the restarted target control device (S246).

[0129] If no response to the retransmitted status confirmation message is received (S247, Yes), the control unit (110) may determine the first test case as a vulnerable case (S248).

[0130] If a response to the status confirmation message is received (S247, No), the control unit (110) may not determine the first test case as a vulnerable case.

[0131] According to one embodiment, when the state of the target control device has changed, the control unit (110) can retransmit the first test case that is not determined as a vulnerable case to the target control device whose state has changed.

[0132] Specifically, the first test case may be a test case determined to be a risk candidate. Accordingly, the first test case injected into the target control device whose state has changed may become a vulnerable case. Accordingly, if the state of the target control device has changed, the control unit (110) may retransmit the first test case to the target control device whose state has changed. Furthermore, the control unit (110) may determine whether to determine the first test case as a vulnerable case based on the response to the status confirmation message.

[0133] According to one embodiment, the fuzzing framework may be configured with a fifth requirement for replaying an attack method against a target control device. The control unit (110) may perform an analysis on whether or not the target control device is abnormal by retransmitting a test case through the fuzzing framework, which is configured with a fifth requirement that enables a retransmission attack using the message when a vulnerability of the target control device is discovered as a result of an attack against the target control device, a fifth requirement that enables automatic replay, and a fifth requirement that enables manual replay.

[0134] The description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments disclosed herein, but is to be construed in the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for evaluating the security of an in-vehicle network performed by a computing device including at least one processor, Step of building a fuzzing framework for performing a security evaluation method; and A step of performing the above security evaluation method using the constructed framework; Including, The above security evaluation method is, Step 1: Extract message list from CAN DB file; A step of generating at least one test case using a message included in the extracted message list; A step of injecting a first test case among the at least one test case into a target control device constituting the in-vehicle network; A step of performing an analysis on whether there is an abnormality in the target control device according to the injection of the first test case; and A step of determining whether to inject a second test case among the at least one test case based on whether the target control device is abnormal; Including, A method for evaluating the security of an in-vehicle network.

2. In paragraph 1, The steps for building a fuzzing framework to perform the above security evaluation method are: Step 1: Establishing requirements for the scope of the fuzzer; A step of constructing a second requirement for at least one test case; Step of establishing a third requirement for the protocol of the above in-vehicle network; Step of establishing a fourth requirement for logging of the above in-vehicle network; Step 5 of establishing requirements for replay of attack methods against target control devices; and Step 6: Establishing requirements for the results report; Including, A method for evaluating the security of an in-vehicle network.

3. In paragraph 2, The first requirement above is, Including at least one of the following requirements: 1-1 for generating a test case for a preset message in the CAN DB file, 1-2 for performing a fuzzing test for a UDS (Unified Diagnostic Services) protocol message, 1-3 for performing fuzzing through randomization for data within a specified range, and 1-4 for performing fuzzing through randomization for the entire CAN message. A method for evaluating the security of an in-vehicle network.

4. In paragraph 2, The second requirement above is, Including at least one of the requirement 2-1 that allows test cases to be generated based on a structure set by the user and the requirement 2-2 that allows modifications to the generated test cases. A method for evaluating the security of an in-vehicle network.

5. In paragraph 2, The third requirement above is, Including at least one of the requirements of Article 3-1 for a protocol for supporting CAN communication and CAN-FD communication and the requirements of Article 3-2 for a protocol for supporting Ethernet. A method for evaluating the security of an in-vehicle network.

6. In paragraph 2, The fourth requirement above is, Including at least one of the requirements of 4-1 for logging all CAN messages within CAN communication, 4-2 for logging all messages on connected CAN communication, and 4-3 for outputting and extracting log files. A method for evaluating the security of an in-vehicle network.

7. In paragraph 2, The fifth requirement above is: In case a vulnerability of the target control device is discovered due to an attack on the target control device, at least one of requirement 5-1 that enables a retransmission attack using the message, requirement 5-2 that enables automatic replay, and requirement 5-3 that enables manual replay, A method for evaluating the security of an in-vehicle network.

8. In paragraph 2, The above 6th requirement is, Including at least one of the requirements of 6-1 for providing a report on discovered vulnerabilities and 6-2 for extracting the final discovered vulnerability results to a local file. A method for evaluating the security of an in-vehicle network.

9. In paragraph 1, The step of generating at least one test case using a message included in the extracted message list is as follows: A step of generating at least one test case according to a fuzzing algorithm; Including, The above fuzzing algorithm is, Comprising at least one of a dump fuzzing algorithm, a generation based fuzzing algorithm, a mutation-based fuzzing algorithm, an evolutionary fuzzing algorithm, and a stateful fuzzing algorithm. A method for evaluating the security of an in-vehicle network.

10. In paragraph 1, The step of performing an analysis on whether there is an abnormality in the target control device according to the injection of the first test case is as follows. A step of transmitting a status check message to the target control device; If no response to the above status check message is received, a step of determining the first test case as a risk candidate; A step of restarting the above target control device; A step of retransmitting the first test case to the restarted target control device; a step of transmitting the status confirmation message to the restarted target control device; and If no response to the above status check message is received, a step of determining the first test case as a vulnerable case; Including, A method for evaluating the security of an in-vehicle network.

11. A computing device for evaluating the security of an in-vehicle network, A control unit that constructs a fuzzing framework for performing a security evaluation method and performs the security evaluation method using the constructed framework; Including, The above security evaluation method is, Step 1: Extract message list from CAN DB file; A step of generating at least one test case using a message included in the extracted message list; A step of injecting a first test case among the at least one test case into a target control device constituting the in-vehicle network; A step of performing an analysis on whether there is an abnormality in the target control device according to the injection of the first test case; and A step of determining whether to inject a second test case among the at least one test case based on whether the target control device is abnormal; Including, Computing device.

Images