Method for evaluating security of in-vehicle network
The method employs security evaluation tools and environments to address security threats in in-vehicle networks, enhancing their resilience against vulnerabilities and attacks through simulated assessments and updates.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- AHOPE
- Filing Date
- 2024-11-22
- Publication Date
- 2026-05-21
AI Technical Summary
The increasing complexity and connectivity of in-vehicle networks in intelligent vehicles pose security threats due to frequent communication with external networks, necessitating a method to evaluate and mitigate potential vulnerabilities and attacks.
A method involving security evaluation tools and environments to assess vulnerabilities and simulate attacks on in-vehicle networks, including fuzzing frameworks, penetration testing, and Over The Air Software Update scenarios, to ensure network security.
Enhances the security of in-vehicle networks by identifying and mitigating potential threats, ensuring reliable and secure software updates, and maintaining network integrity.
Smart Images

Figure KR2024018583_21052026_PF_FP_ABST
Abstract
Description
Method for evaluating the security of an in-vehicle network
[0001] The present disclosure relates to a method for scheduling a battery, and specifically to a method for scheduling a battery for the operation of a mobile body.
[0002] The transportation environment of modern society is gradually evolving into an intelligent transportation system. In line with this advancement, intelligent vehicles equipped with features such as infotainment, safety, road assistance, and telematics are being released.
[0003] With the introduction of various in-vehicle functions in intelligent vehicles, the number of Electronic Control Units (ECUs) and electrical and electronic components has increased significantly. Electronic control units are installed throughout the vehicle and can perform sensing and computation related to the control of the vehicle body. There can be various types of ECUs, such as EGN (Engine) ECUs, ABS (Anti-lock Braking System) ECUs, multimedia ECUs, transmission ECUs, and safety-related ECUs, and there can be approximately 60 to 100 of them in a single vehicle.
[0004] ECUs have a hierarchical structure and perform their own unique functions while also performing cooperative control with other ECUs. An In-Vehicle Network (IVN) can be used for communication between ECUs. Examples of In-Vehicle Networks include CAN (Controller Area Network), CAN FD (CAN with Flexible Data Rate), or Ethernet.
[0005] Meanwhile, as vehicle software becomes more complex, the functions of ECUs are evolving rapidly. ECUs are frequently updated to new versions to accommodate the addition of new features, performance improvements, or the detection of vehicle anomalies. ECU updates can be performed via wireless or wired communication between the vehicle's internal network and external networks. Communication between the internal and external networks is expected to become even more frequent with the advancement of autonomous driving technology.
[0006] While it may be semi-essential for an internal vehicle network to communicate with an external network to improve vehicle performance, this can increase security threats to the internal vehicle network or ECU.
[0007] The present disclosure is conceived in response to the aforementioned background technology and aims to provide a method for evaluating the security of an internal vehicle network.
[0008] The technical problems of the present disclosure are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below.
[0009] According to one embodiment of the present disclosure for solving the problem described above, a method for evaluating the security of an internal vehicle network performed by a computing device comprising at least one processor is disclosed. The method for evaluating the security of the internal vehicle network may include: a step of constructing a first security evaluation tool for performing a security evaluation method of an internal network in which communication between a plurality of control devices is performed, wherein the first security evaluation tool is a tool for evaluating security regarding unknown vulnerabilities; a step of constructing a second security evaluation tool for performing the security evaluation method, wherein the second security evaluation tool is a tool for evaluating whether there is a possibility of attack; and a step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool.
[0010] Additionally, the step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool may include: a step of establishing a security evaluation environment for evaluating security in an Over The Air Software Update environment; and a step of performing the security evaluation method using at least one of the first security evaluation tool, the second security evaluation tool, and the security evaluation environment.
[0011] In addition, the security evaluation environment may perform the following operations: checking the version of the firmware of the plurality of control devices; requesting the latest version of the firmware from a pre-designated server in a Hardware-in-the-Loop (HILS) test environment in which the plurality of control devices communicate within a virtual vehicle environment; and updating the firmware by obtaining an update package for installing the latest version of the firmware from the pre-designated server through the HILS test environment.
[0012] Additionally, the security evaluation environment includes a third security evaluation tool that performs an attack on at least one of a plurality of operations in which a wireless software update is performed, and the third security evaluation tool may include at least one of a first scenario in which a fake server is set up to distribute a malicious update, a second scenario in which the updated firmware is downgraded, a third scenario in which malicious code is inserted into an update package for installing the latest version of the firmware, a fourth scenario in which communication between the plurality of control devices and the HILS test environment, or communication between the HILS test environment and the pre-specified server is intercepted, a fifth scenario in which an unnecessary update is performed, a sixth scenario in which malicious code is inserted into a cache area for performing the update, a seventh scenario in which administrator access to the update system is attempted, an eighth scenario in which malicious code is inserted into the update installation process, a ninth scenario in which a key used for encryption or signing of the update package is stolen, and a tenth scenario in which manipulation is performed on the update package to induce the installation of an incompatible update.
[0013] Additionally, the step of performing the security evaluation method using at least one of the first security evaluation tool, the second security evaluation tool, and the security evaluation environment may include: performing a wireless software update in the security evaluation environment; injecting at least one scenario using the third security evaluation tool while the wireless software update is being performed; and transmitting the result of performing the wireless software update and the result of injecting the at least one scenario to the pre-specified server.
[0014] Additionally, the step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool may include: 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 the first test case among the at least one test case into a target control device constituting the vehicle internal network; performing an analysis of whether there is an abnormality in the target control device based on the injection of the first test case; and performing the security evaluation method using the first security evaluation tool by determining whether to inject the second test case among the at least one test case based on whether there is an abnormality in the target control device.
[0015] Additionally, a computer program stored on a computer-readable storage medium, wherein the computer program, when executed on one or more processors, performs a method for evaluating the security of an internal network of a vehicle, and the method may include: a step of establishing a first security evaluation tool for performing a method for evaluating the security of an internal network in which communication between a plurality of control devices is performed, wherein the first security evaluation tool is a tool for evaluating security regarding unknown vulnerabilities; a step of establishing a second security evaluation tool for performing the security evaluation method, wherein the second security evaluation tool is a tool for evaluating whether there is a possibility of attack; and a step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool.
[0016] The technical solutions obtainable in this disclosure are not limited to the solutions mentioned above, and other solutions not mentioned will be clearly understood by those skilled in the art to which this disclosure belongs from the description below.
[0017] According to some embodiments of the present disclosure, a method for evaluating the security of an internal vehicle network can be provided so that a security system safe from threats to the vehicle system can be established.
[0018] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.
[0019] Various aspects are now described with reference to the drawings, wherein similar reference numbers are used to collectively refer to similar components. In the following embodiments, for illustrative purposes, a number of specific details are presented to provide a comprehensive understanding of one or more aspects. However, it will be apparent that such aspect(s) may be practiced without these specific details. In other examples, known structures and devices are illustrated in block diagram form to facilitate the description of one or more aspects.
[0020] FIG. 1 is a block diagram illustrating an example of a computing device according to some embodiments of the present disclosure.
[0021] FIG. 2 is a flowchart illustrating an example of a computing device according to some embodiment of the present disclosure performing a method for evaluating the security of an internal vehicle network.
[0022] FIG. 3 is a flowchart illustrating an example of an operation performed in a security evaluation environment implemented by a computing device according to some embodiments of the present disclosure.
[0023] FIG. 4 illustrates an example of a method in which a computing device according to some embodiments of the present disclosure performs a security evaluation method using a security evaluation environment.
[0024] FIG. 5 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure.
[0025] FIG. 6 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure.
[0026] FIG. 7 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure.
[0027] The present invention is susceptible to various modifications and may have various embodiments; specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the invention to specific embodiments, and it should be understood that the invention includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the invention. Similar reference numerals have been used for similar components in the description of each drawing.
[0028] Terms such as first, second, A, B, etc., may be used to describe various components, but said components should not be limited by said terms. These terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component. The term "and / or" includes a combination of a plurality of related described items or any of a plurality of related described items.
[0029] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.
[0030] The terms used in this application are used merely to describe specific embodiments and are not intended to limit the invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, terms such as "comprising" or "having" are intended to specify the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.
[0031] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.
[0032] In the present disclosure, a computing device can evaluate the security of an in-vehicle network by performing a security evaluation method. The computing device may establish security evaluation tools to perform the security evaluation method. For example, the computing device may establish a first security evaluation tool to evaluate security regarding unknown vulnerabilities. The computing device may establish a second security evaluation tool to evaluate the possibility of an attack. The computing device may establish a third security evaluation tool to perform an attack on the operation of performing a wireless software update. The computing device may evaluate the security of an in-vehicle network by performing a security evaluation method using a plurality of established security evaluation tools. A method for a computing device to evaluate the security of an in-vehicle network according to the present disclosure will be described below with reference to FIGS. 1 to 7.
[0033] FIG. 1 is a block diagram illustrating an example of a computing device according to some embodiments of the present disclosure.
[0034] Referring to FIG. 1, the 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), so the computing device (100) may have more or fewer components than the components listed above.
[0035] 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.
[0036] A computing device (100) may achieve desired system performance by using a combination of typical computer hardware (e.g., a device that may include a computer processor, memory, storage, input device and output device, and other components of a conventional computing device; electronic communication devices such as routers and switches; and electronic information storage systems such as network-attached storage (NAS) and storage area network (SAN)) and computer software (i.e., instructions that cause the computing device to function in a specific way).
[0037] The control unit (110) can typically handle the overall operation of the computing device (100). The control unit (110) can provide or process appropriate information or functions to the user by processing signals, data, information, etc. that are input or output through the components of the computing device (100) or by running an application program stored in the storage unit (120).
[0038] 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).
[0039] In the present disclosure, the control unit (110) can establish a security evaluation tool to perform a security evaluation method.
[0040] For example, the control unit (110) may construct a first security evaluation tool for evaluating security against unknown vulnerabilities. The first security evaluation tool may be constructed as a fuzzing framework, etc. Fuzzing may be a method for testing unknown vulnerabilities in software. A fuzzing framework may be understood as a tool constructed to test vulnerabilities in software. In other words, the first security evaluation tool may be understood as a tool for evaluating security against unknown vulnerabilities.
[0041] As another example, the control unit (110) may establish a second security assessment tool to perform an assessment of whether there is a possibility of an attack. The second security assessment tool may be a tool for penetration testing. Penetration testing may be implemented according to test guidelines for which guidelines are generally known and exist. For example, the second security assessment tool may be implemented to perform Penetration (PEN) testing, vulnerability testing identified by Threat Analysis and Risk Assessment (TARA), application security testing such as Open Web Application Security Project (OWAS), and penetration testing execution standards such as Penetration Testing Execution Standard (PTES).
[0042] As another example, the control unit (110) may establish a third security evaluation tool that performs an attack on at least one of a plurality of operations in which a wireless software update is performed. The third security evaluation tool is a tool for performing an attack while a plurality of control devices related to an in-vehicle network, such as an ECU, are being updated wirelessly. Hereinafter, an example of a method by which the control unit (110) establishes the first security evaluation tool to the third security evaluation tool is described through FIGS. 2 to 4.
[0043] 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.), RAM (Random Access Memory), SRAM (Static Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), PROM (Programmable Read-Only Memory), magnetic memory, a magnetic disk, and an optical disk.
[0044] In the present disclosure, the storage unit (120) may store a database built by the control unit (110). The control unit (110) may store, retrieve, or modify test models for generating test cases built in the database, fuzzing algorithms, known vulnerabilities, attack scenarios, security threats, and vulnerability information.
[0045] 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 the vehicle, or between the computing device (100) and the network.
[0046] Below, a specific example of a computing device (100) evaluating the security of a vehicle internal network is described.
[0047] FIG. 2 is a flowchart illustrating an example of a computing device according to some embodiment of the present disclosure performing a method for evaluating the security of an internal vehicle network.
[0048] Referring to FIG. 2, the control unit (110) of the computing device (100) may establish a first security evaluation tool for performing a security evaluation method of an internal network in which communication between a plurality of control devices is performed (S110). The first security evaluation tool may be a tool for evaluating security against unknown vulnerabilities.
[0049] For example, the first security assessment tool can be built using a fuzzing framework, etc. Fuzzing can be a method for testing software vulnerabilities. A fuzzing framework can be understood as a tool built to test software vulnerabilities.
[0050] According to one embodiment, the control unit (110) may construct a first security evaluation tool to include at least one requirement. Here, the requirement may be understood as defining the performance that the fuzzing framework must satisfy.
[0051] The control unit (110) can establish a first requirement for the range of the fuzzer. A fuzzer is a method of injecting semi-random data into target software and can be understood as a concept identical or similar to fuzzing. The range of the fuzzer can be understood as the range in which data is generated. The range of the 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 range of the fuzzer.
[0052] The first requirement may include at least one of the 1-1 to 1-4 requirements.
[0053] The 1-1 requirement may be a requirement for generating test cases for pre-configured 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 establish the 1-1 requirement to perform a security evaluation method by reading the CAN DB file and generating test cases for pre-configured messages within the database.
[0054] The first-2 requirement may be a requirement for performing a fuzzing test on a UDS (Unified Diagnostic Services) protocol message. The UDS protocol may be a diagnostic communication protocol used for the diagnosis, testing, or repair of an Electronic Control Unit (ECU) within a vehicle. The UDS protocol message may be a message transmitted to perform the aforementioned operation. The control unit (110) may establish the first-2 requirement to perform a security evaluation method on the UDS protocol message.
[0055] The first-third requirement may be a requirement to perform fuzzing through randomization of data within a specified range. The control unit (110) may establish the first-third requirement so that a security evaluation method is performed in which fuzzing is performed through randomization of data within a specified range.
[0056] The first-fourth requirement may be a requirement to perform fuzzing through randomization of the entire CAN message. The control unit (110) may establish the first-fourth requirement so that a security evaluation method is performed in which fuzzing is performed through randomization of the entire CAN message.
[0057] The control unit (110) can establish a second requirement for at least one test case. The test case may be an attack to be injected into a target control unit. Here, the target control unit may be an Electronic Control Unit (ECU) or a Domain Control Unit (DCU). The target control unit may be a control unit to evaluate security.
[0058] The second requirement may include at least one of the 2-1 requirement and the 2-2 requirement.
[0059] The second-first requirement may be a requirement that test cases be generated based on a structure set by the user. The structure may be understood as the structure of the test case. When the control unit (110) performs a security evaluation method, it may establish the second-first requirement so that test cases are generated based on a structure set by the user.
[0060] The second-2 requirement may be a requirement that allows modification to the generated test case. The control unit (110) may establish the second-2 requirement to allow modification to the generated test case.
[0061] The control unit (110) can establish a third requirement for the protocol of the vehicle internal network. The protocol of the vehicle internal network can be understood as a communication protocol.
[0062] The third requirement may include at least one of the 3-1 requirement and the 3-2 requirement.
[0063] The 3-1 requirement may be a requirement for a protocol for supporting CAN communication and CAN-FD communication. When the control unit (110) performs a security evaluation method, it may establish the 3-1 requirement so that the security evaluation method can be performed through a protocol for supporting CAN communication and CAN-FD communication.
[0064] The third-2 requirement may be a requirement for a protocol for Ethernet support. When the control unit (110) performs a security evaluation method, it may establish the third-2 requirement so that the security evaluation method can be performed through a protocol for Ethernet support.
[0065] The control unit (110) can establish a fourth requirement for logging of the vehicle internal network. Logging may be an operation of recording a log, which is operational information of the system.
[0066] The fourth requirement may include at least one of the 4-1 to 4-3 requirements.
[0067] The 4-1 requirement may be a requirement for logging all CAN messages within the CAN communication. When the control unit (110) performs a security evaluation method, the 4-1 requirement may be established so that logging of all CAN messages within the CAN communication is performed.
[0068] The 4-2 requirement may be a requirement for logging all messages on the connected CAN communication. When the control unit (110) performs a security evaluation method, the 4-2 requirement may be established so that logging of all messages on the connected CAN communication is performed.
[0069] The 4-3 requirement may be a requirement for outputting and extracting a log file. When the control unit (110) performs a security evaluation method, it may establish the 4-2 requirement so that outputting and extracting of the log file is performed.
[0070] The control unit (110) can establish a fifth requirement for a replay of an attack method on a target control device.
[0071] The fifth requirement may include at least one of the 5-1 to 5-3 requirements.
[0072] The 5-1 requirement may be a requirement that enables a retransmission attack using the corresponding message when a vulnerability of the target control device is discovered following an attack on the target control device. The control unit (110) may establish the 5-1 requirement to enable a retransmission attack using the corresponding message when a vulnerability of the target control device is discovered following an attack on the target control device by performing a security evaluation method.
[0073] The 5-2 requirement may be a requirement to automatically proceed with replay. The control unit (110) may establish the 5-2 requirement so that if a vulnerability of the target control device is discovered due to an attack on the target control device by performing a security evaluation method, replay is automatically proceeded.
[0074] The 5-3 requirement may be a requirement to allow a replay to proceed manually. The control unit (110) may establish the 5-3 requirement to allow a replay to proceed manually when a vulnerability of the target control device is discovered due to an attack on the target control device by performing a security evaluation method.
[0075] The control unit (110) can establish a sixth requirement for the result report.
[0076] The 6th requirement may include at least one of the 6-1 requirement and the 6-2 requirement.
[0077] The 6-1 requirement may be a requirement to provide a report on discovered vulnerabilities. The control unit (110) may establish the 6-1 requirement so that if vulnerabilities are discovered by performing a security evaluation method, a report on discovered vulnerabilities is provided.
[0078] Requirement 6-2 may be a requirement for extracting the final discovered vulnerability results into a local file. The control unit (110) may establish the 6-2 requirement so that the final discovered vulnerability results are extracted into a local file.
[0079] The control unit (110) may construct a second security evaluation tool for performing a security evaluation method (S120). The second security evaluation tool may be a tool for performing an evaluation of whether there is a possibility of an attack.
[0080] The second security assessment tool may be a tool for penetration testing. Penetration testing may be implemented according to test guidelines for which guidelines are generally known and exist. For example, the second security assessment tool may be implemented to perform Penetration (PEN) testing, vulnerability testing identified by Threat Analysis and Risk Assessment (TARA), application security testing such as Open Web Application Security Project (OWAS), and penetration testing execution standards such as Penetration Testing Execution Standard (PTES).
[0081] The control unit (110) can perform a security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool (S130).
[0082] Specifically, the control unit (110) can evaluate the security of a target control unit or an internal network by injecting an attack into an internal network where communication between control units within a vehicle is performed using at least one of a first security evaluation tool and a second security evaluation tool.
[0083] According to one embodiment, the control unit (110) can establish a test environment in which a plurality of control devices communicate within a virtual vehicle environment.
[0084] For example, if the target control device is a physical device, the control unit (110) can establish a Hardware-in-the-Loop Simulation (HILS) test environment that enables the target control device to perform communication within a virtual vehicle environment. The control unit (110) can control the target control device to enable the target control device to perform communication in the established HILS test environment.
[0085] For example, a computing device (100) may be connected to a target control device via a harness. A control unit (110) may control the target control device via the harness so that the target control device performs operations within a 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) may be connected to the simulator in which the test environment is established via a harness, etc. A control unit (110) may control the simulator or the target control device via the harness so that the target control device performs operations within a HILS test environment implemented by the simulator.
[0086] In another example, if the target control device is a virtual device, the control unit (110) can establish a Software-in-the-Loop Simulation (SILS) test environment that enables the target control device to perform communication within a virtual vehicle environment. The control unit (110) can control the virtual target control device so that the target control device performs communication within the established 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) may be connected to the simulator in which the test environment is established via a harness, etc. The control unit (110) can control the simulator or the target control device via the harness so that the target control device performs communication within the SILS test environment implemented by the simulator.
[0087] Security evaluation methods can be performed using black box testing, gray box testing, and white box testing techniques, depending on the level of understanding of the software under analysis.
[0088] Black box testing is a testing technique performed without prior knowledge of the source code, internal structure, or internal operations of the software under analysis. When using black box testing, the tester possesses only knowledge of the program's input and output values and can perform tests based on exceptions observed from outside the program. Black box testing allows even general users without specialized knowledge to perform tests, and while test case generation time is relatively shorter compared to white box testing, code coverage may be lower. Examples of black box testing techniques include Equivalence Partitioning, Boundary Value Analysis, Cause-Effect Graph, Orthogonal Array Testing, and State Transition Testing.
[0089] Gray box testing is a testing technique performed with limited knowledge of the internal workings of the software under analysis. When using gray box testing, the tester must possess some prior knowledge of the program's internal data structures or algorithms. Gray box testing can combine the advantages of both black-box and white-box testing, but it generally results in lower code coverage compared to white-box testing. Examples of gray box testing techniques include orthogonal array testing, matrix testing, regression testing, and pattern testing.
[0090] White box testing is a testing technique performed with prior knowledge of the internal logic and structure of the software under analysis. When using white box testing, the tester must possess all necessary knowledge of the program's source code and may need to have a certain level of expertise regarding the program to execute the tests. White box testing can detect implementation errors or hidden code errors that are difficult to find using black box testing. Because white box testing involves knowledge of the source code, it offers high code coverage; however, the time required to generate test cases may be relatively longer compared to black box testing. Examples of white box testing techniques include Control Flow Testing, Branch Testing, Basis Path Testing, Data Flow Testing, and Loop Testing.
[0091] According to one embodiment, the control unit (110) can extract a message list from a CAN DB file through a first security evaluation tool in which a first requirement for the range of the fuzzer is established. The control unit (110) can generate at least one test case using the messages included in the extracted message list. Here, the test case may be a case for an attack on a target control device. The control unit (110) can generate at least one test case through a first security evaluation tool in which a second requirement for at least one test case is established.
[0092] Specifically, the control unit (110) can generate at least one test case according to a fuzzing algorithm. The fuzzing algorithm may be an algorithm that generates an attack script by inputting numerous different data to find the location of a vulnerability where a collision occurs. The control unit (110) can generate at least one test case using the generated attack script.
[0093] 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.
[0094] A dumb 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 dumb fuzzing algorithm that randomly generates given input values. Here, the system or target system may refer to a target control device and a vehicle internal network.
[0095] 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 the target to be fuzzed tested in the form of a Python script and generates test cases based thereon. A generation-based fuzzing algorithm may generate test cases based on format information of data input into the target system. A generation-based fuzzing algorithm may be an algorithm that extracts information regarding message structure, type, and internal message fields from a specification or RFC document and generates test cases by adding abnormal data to a part of a normal input format. The control unit (110) may generate test cases by adding abnormal data to a part of a normal input format through a generation-based fuzzing algorithm.
[0096] A mutation-based fuzzing algorithm may be an algorithm that collects legitimate data input into a target system and utilizes it as a test case. A mutation-based fuzzing algorithm may be an algorithm that generates test cases by adding abnormal data to legitimate data collected from files or network traffic. The control unit (110) can generate test cases by adding abnormal data to legitimate data through a mutation-based fuzzing algorithm.
[0097] The 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. The incremental fuzzing algorithm may be an algorithm that assigns scores to the performed test cases based on the target system's response to the fuzzing, and utilizes the test cases with high scores for the generation of the next test case. The control unit (110) may provide fuzzing data to the target system through the incremental fuzzing algorithm and then determine the generation of the next fuzzing data based on the system's response.
[0098] 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 the method of processing input differs for each state, the control unit (110) may generate test cases using a state-based fuzzing algorithm.
[0099] The control unit (110) may generate at least one test case using at least one algorithm among a dumb fuzzing algorithm, a generative-based fuzzing algorithm, a mutation-based fuzzing algorithm, an incremental fuzzing algorithm, and a state-based fuzzing algorithm, depending on the type of vehicle internal network or target control device. The control unit (110) may inject the first test case among the at least one test case into the target control device constituting the vehicle internal network. Alternatively, the control unit (110) may inject the first test case into the vehicle internal network. The control unit (110) may inject the first test case into the target control device through a first security evaluation tool in which a third requirement for the protocol of the vehicle internal network is established. The control unit (110) may perform an analysis of whether there is an abnormality in the target control device following the injection of the first test case. The control unit (110) may inject the first test case into the target control device. The control unit (110) may transmit a status check message to the target control device. Additionally, the control unit (110) can determine whether there is an abnormality in the target control device based on whether a response to a status check message is received. Based on whether there is an abnormality in the target control device, the control unit (110) can perform a security evaluation method using the first security evaluation tool by determining whether to inject a second test case among at least one test case. For example, if the control unit (110) determines that an abnormality has occurred in the target control device, it may determine the first test case as a vulnerable case. And, the control unit (110) may not inject the second test case. As another example, if the control unit (110) determines that no abnormality has occurred in the target control device, it may inject the second test case.
[0100] According to another embodiment, the control unit (110) can perform a security evaluation method using a second security evaluation tool by performing a vulnerability test identified by PEN test or TARA.
[0101] According to the above configuration, the computing device (100) may establish a first security evaluation tool and a second security evaluation tool to perform a security evaluation method. Then, the computing device (100) may perform a security evaluation method for a target control device using the established security evaluation tools. Accordingly, the reliability of the performed security evaluation may be excellent.
[0102] Meanwhile, according to some embodiments of the present disclosure, a computing device (100) may establish a third security evaluation tool that performs an attack on at least one of a plurality of operations in which a wireless software update is performed. The computing device (100) may establish a security evaluation environment for performing a security evaluation method using the third security evaluation tool. For example, the computing device (100) may establish a security evaluation environment for evaluating security in an Over The Air Software Update environment. Furthermore, the computing device (100) may perform a security evaluation method using at least one of the first security evaluation tool, the second security evaluation tool, and the security evaluation environment. Hereinafter, an example of an operation performed in a security evaluation environment implemented by the computing device (100) according to the present disclosure is described with reference to FIG. 3.
[0103] FIG. 3 is a flowchart illustrating an example of an operation performed in a security evaluation environment implemented by a computing device according to some embodiments of the present disclosure.
[0104] Referring to FIG. 3, the control unit (110) can perform an operation to check the firmware versions of a plurality of control devices in a security evaluation environment (S131). The plurality of control devices may include a first ECU and a second ECU. The first ECU may be a target control device. The second ECU may be a device for controlling the target control device. The first ECU may be an agent device, and the second ECU may be an ECU application that controls the first ECU, etc. The operations performed by the plurality of control devices, the HILS test environment, and the external server described below can be understood as operations within the security evaluation environment established by the control unit (110).
[0105] Specifically, the control unit (110) can boot a plurality of control devices. The control unit (110) can request the second ECU to check the version of the current firmware of the first ECU through the first ECU. The control unit (110) can transmit the version of the current firmware to the first ECU through the second ECU.
[0106] The control unit (110) can request the latest version of firmware from a pre-designated server in a Hardware-in-the-Loop (HILS) test environment in which a plurality of control devices communicate within a virtual vehicle environment (S132).
[0107]
[0108] Specifically, the control unit (110) can request the latest version of the firmware from the gateway in a HILS test environment. The gateway may be an environment that enables communication between networks using different communication networks or different protocols in a network environment. The gateway may enable communication between the ECU and the OTA (Over The Air) server. The OTA server may be a server for wireless software upgrades of multiple control devices or target control devices. The OTA server may upload the latest version of the firmware to an FTP (File Transfer Protocol) server. An FTP server may be a network protocol designed for file transfer. By uploading the latest version of the firmware to the FTP server, the OTA server can prevent HILS, etc., from performing a direct download from the OTA server. The control unit (110) can view the file list uploaded to the FTP server through the gateway. The control unit (110) can transmit the latest version of the firmware to HILS through the gateway. The control unit (110) can transmit the latest version of the firmware and filenames to multiple control devices through HILS.
[0109] The control unit (110) can update the firmware by obtaining an update package for installing the latest version of the firmware from a pre-specified server through a HILS test environment (S133).
[0110] Specifically, the control unit (110) can transmit the latest version of the firmware and filename to multiple control devices via HILS. The control unit (110) can enable multiple control devices to obtain an update package via HILS. And, the control unit (110) can enable multiple control devices to update the firmware.
[0111] The control unit (110) may establish a third security evaluation tool that performs an attack on a plurality of control devices in an implemented security evaluation environment. The third security evaluation tool may be a tool that performs an attack on at least one of a plurality of operations in which a wireless software update is performed. In other words, the third security evaluation tool may be a tool that performs an attack on a plurality of control devices, other components within the security evaluation environment, or the security evaluation environment during the execution of steps S131 to S133.
[0112] The third security evaluation tool may include multiple scenarios for performing an attack on the security evaluation environment. The third security evaluation tool may include scenarios 1 through 10, etc.
[0113] The first scenario may be one in which a fake server is set up to distribute malicious updates. The first scenario may be one in which malicious updates are distributed by creating a fake server instead of an FTP server, OTA server, or gateway.
[0114] The control unit (110) can direct traffic to a fake update server through Domain Name System (DNS) spoofing or a man-in-the-middle attack. The control unit (110) can attempt an HTTPS connection with a forged certificate.
[0115] The second scenario may be a scenario in which updated firmware is downgraded. The second scenario may be a scenario in which the latest version of firmware updated on multiple control devices is downgraded through an update operation. The second scenario may be a scenario in which firmware installed on multiple control devices is downgraded before the update operation is performed.
[0116] The control unit (110) can obtain a normal update file of a previous version. The control unit (110) can attempt to install a previous version through an OTA process.
[0117] A third scenario may be a scenario in which malicious code is inserted into an update package for installing the latest version of firmware. A third scenario may be a scenario in which malicious code is inserted into an update package delivered to multiple control devices. A third scenario may be a scenario in which malicious code is inserted into an update package delivered from a gateway to HILS. A third scenario may be a scenario in which malicious code is inserted into an update package delivered from HILS to multiple control devices.
[0118] The control unit (110) can obtain a normal update package and perform reverse engineering. The control unit (110) can attempt to re-sign the package after inserting malicious code into it. The control unit (110) can proceed with the update using the modified package.
[0119] The fourth scenario may be a scenario in which communication between multiple control devices and a HILS test environment is intercepted. The fourth scenario may be a scenario in which communication between a HILS test environment and a pre-specified server is intercepted. The fourth scenario may be a scenario in which communication between a HILS test environment and a gateway is intercepted.
[0120] The control unit (110) can configure a Man In The Middle (MITM) attack environment through Address Resolution Protocol (ARP) spoofing or Wi-Fi jamming. The control unit (110) can capture and analyze update traffic. The control unit (110) can attempt to tamper with the traffic.
[0121] Scenario 5 may be a scenario in which unnecessary updates are performed. Scenario 5 may be a scenario in which multiple control devices perform unnecessary updates. Scenario 5 may be a scenario in which a Denial of Service (DoS) state is caused.
[0122] The control unit (110) can perform analysis and reproduction of update confirmation request packets. The control unit (110) can send a large number of update confirmation requests.
[0123] Scenario 6 may be a scenario in which administrator access to the update system is attempted. Scenario 6 may be a scenario in which administrator access to the update system is attempted by exploiting a low-privilege vulnerability.
[0124] The control unit (110) can scan for known vulnerabilities in the vehicle system. The control unit (110) can attempt privilege escalation through the discovered vulnerabilities. The control unit (110) can attempt to access the update system with elevated privileges.
[0125] Scenario 7 may be a scenario in which malicious code is inserted into a cache area for performing an update. Multiple control devices may utilize a cache area or a temporary memory area to install an update package. Scenario 7 may be a scenario in which malicious code is inserted into a cache area or a temporary memory area.
[0126] The control unit (110) can identify the update download path and the location of the temporary storage. The control unit (110) can attempt to obtain write permissions for the storage. The control unit (110) can trigger the update process after injecting malicious code.
[0127] Scenario 8 may be a scenario in which malicious code is inserted during the update installation process. Scenario 8 may be a scenario in which malicious code is inserted during the process in which multiple control devices use an update package to install the latest version of the firmware.
[0128] The control unit (110) can perform analysis of the update installation process and vulnerability detection. The control unit (110) can apply Dynamic Link Library (DLL) injection or code hooking techniques. The control unit (110) can attempt to inject malicious code during the execution of the update process.
[0129] Scenario 9 may be a scenario in which the key used for encryption or signing of the update package is stolen. The update package may be encrypted and transmitted to multiple control devices. Scenario 9 may be a scenario in which the key used for encryption, signing, or decryption, etc., is stolen.
[0130] The control unit (110) can analyze the key store location and protection mechanism. The control unit (110) can attempt an attack on a memory dump or side-channel. The control unit (110) can attempt to create a malicious update package using the acquired key.
[0131] Scenario 10 may be a scenario in which manipulation is performed on an update package to induce the installation of an incompatible update. Scenario 10 may be a scenario in which firmware that is unavailable on multiple control devices is installed.
[0132] The control unit (110) can analyze the structure of the update metadata. The control unit (110) can perform operations on important fields such as compatibility information and version numbers. The control unit (110) can proceed with the update process using the manipulated metadata.
[0133] The control unit (110) can perform a security evaluation method by performing attacks on a security evaluation environment through a third security evaluation tool established. Hereinafter, an example of a method in which a computing device (100) according to the present disclosure performs a security evaluation method using a security evaluation environment is described with reference to FIG. 4.
[0134] FIG. 4 illustrates an example of a method in which a computing device according to some embodiments of the present disclosure performs a security evaluation method using a security evaluation environment.
[0135] Referring to FIG. 4, the control unit (110) of the computing device (100) can perform a wireless software update in a security evaluation environment (S210).
[0136] Specifically, the control unit (110) can enable a plurality of control devices to perform wireless software updates in a security evaluation environment where steps S131 to S133 can be performed.
[0137] The control unit (110) can inject at least one scenario using a third security evaluation tool while a wireless software update is being performed (S220). By injecting scenarios 1 through 10, the control unit (110) can perform an attack on the security evaluation environment.
[0138] The control unit (110) can transmit the result of performing a wireless software update and the result of injecting at least one scenario to a pre-specified server (S230). The pre-specified server may be an FTP server, an OTA server, or a gateway, etc.
[0139] The result of performing a wireless software update can indicate whether the wireless software update was successful or failed.
[0140] The injection result of the first scenario may indicate whether the vehicle rejected the connection upon certificate validity verification failure. The injection result of the first scenario may indicate whether the update server address was hardcoded or securely stored.
[0141] The injection result of the second scenario may indicate whether the detection and prevention of version downgrade attempts have been performed. The injection result of the second scenario may indicate the existence of a secure management and verification mechanism for software versions.
[0142] The injection result of the third scenario can indicate the existence and effectiveness of the package integrity verification mechanism. The injection result of the third scenario can indicate the strength of the code signature verification.
[0143] The injection result of the fourth scenario may indicate the presence of communication encryption and integrity protection mechanisms. The injection result of the fourth scenario may indicate whether advanced MITM prevention techniques, such as SSL Pinning, are applied.
[0144] The injection result of the fifth scenario may indicate whether an update request frequency limiting mechanism exists. The injection result of the fifth scenario may indicate the capability to detect abnormal update request patterns.
[0145] The injection result of Scenario 6 may indicate whether the principle of least privilege is applied. The injection result of Scenario 6 may indicate the level of privilege separation and update system isolation.
[0146] The injection result of Scenario 7 may indicate the access control and encryption level of the update cache. The injection result of Scenario 7 may indicate the presence of a pre-installation cache integrity verification mechanism.
[0147] The injection result of Scenario 8 may indicate the existence of code integrity verification and execution control mechanisms. The injection result of Scenario 8 may indicate whether a secure update installation environment is provided.
[0148] The injection result of Scenario 9 may indicate whether the encryption key is securely stored and used. The injection result of Scenario 9 may indicate whether a Hardware Security Module (HSM) is used. The injection result of Scenario 8 may indicate the appropriateness of the key rotation and revocation policy.
[0149] The injection result of Scenario 10 may indicate the existence of a metadata integrity verification mechanism. The injection result of Scenario 10 may indicate the thoroughness of compatibility and version verification prior to the update.
[0150] According to the above configuration, the computing device (100) can inject at least one scenario using a third security evaluation tool while a wireless software update is being performed. The computing device (100) can transmit the injection result of at least one scenario through the third security evaluation tool to a pre-designated server. Additionally, the computing device (100) can analyze the injection result of at least one scenario. Accordingly, vulnerabilities in the security evaluation environment, etc., can be analyzed.
[0151] Below, an example of an operation performed in the security evaluation environment described in FIGS. 3 and FIGS. 4 is described. Content that overlaps with what was previously described is omitted below.
[0152] FIG. 5 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure. FIG. 6 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure. FIG. 7 is a drawing for illustrating an example of an operation performed in a security evaluation environment according to some embodiments of the present disclosure.
[0153] Referring to FIGS. 5 to 7, the FTP server can download an updated firmware file from the OTA server (S310).
[0154] The control unit can request the latest version of the firmware via HILS (S320).
[0155] HILS can request the latest version of the firmware from the gateway (S330).
[0156] The gateway can query the file list from the FTP server (S340). The FTP server can transmit the file list to the gateway. The FTP server can check whether a newer version exists within the FTP server. If a newer version does not exist, the FTP server can download the newer version of the firmware by waiting for a predetermined period of time.
[0157] The FTP server can transmit the latest version and file name to HILS (S350).
[0158] HILS can transmit the latest version and file name to the control device (S360).
[0159] The control device may request firmware file information from HILS in response to an update request (S370). Acceptance of the update request may also be performed by the user.
[0160] HILS can request firmware file information from the gateway (S380).
[0161] The gateway can query the file information size from the FTP server (S390).
[0162] The gateway can transmit the file size to HILS (S400).
[0163] The control device can request the HILS to download the firmware (S410).
[0164] HILS can request the gateway to download the firmware (S420)
[0165] The gateway can request the download of firmware from the FTP server (S430).
[0166] The gateway can download firmware from the FTP server (S440).
[0167] HILS can download firmware from the gateway (S450).
[0168] The control device can download firmware from the gateway (S460).
[0169] The control device can check the download progress (S470).
[0170] The control device can perform decoding of the firmware (S480).
[0171] The control device can perform an update and a restart (S490).
[0172] The control device can compare the current version and the latest information (S500).
[0173] The control device can transmit the firmware update status to HILS (S510).
[0174] HILS can transmit the firmware update status to the gateway (S520).
[0175] The third security evaluation tool can inject multiple scenarios while steps S310 through S520 are being performed. The third security evaluation tool can transmit the evaluation results to the gateway (S530).
[0176] The gateway can transmit the firmware update status and evaluation results to an FTP server (S540).
[0177] Description of the presented embodiments is provided so that a person skilled in the art may use or practice the present disclosure. Various modifications to these embodiments will be apparent to a person 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. Thus, the present disclosure is not limited to the embodiments presented herein, but should be interpreted in the broadest possible scope consistent with the principles and novel features presented herein.
Claims
1. A method for evaluating the security of an in-vehicle network performed by a computing device comprising at least one processor, wherein A step of establishing a first security evaluation tool for performing a security evaluation method of an internal network in which communication between multiple control devices is performed - the first security evaluation tool is a tool for evaluating security regarding unknown vulnerabilities - ; Step of constructing a second security evaluation tool for performing the above security evaluation method - the second security evaluation tool is a tool for performing an evaluation of whether there is a possibility of attack - ; and A step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool; including, method.
2. In Paragraph 1, The step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool is: A step of establishing a security evaluation environment to evaluate security in an Over The Air Software Update environment; and A step of performing the security evaluation method using at least one of the first security evaluation tool, the second security evaluation tool, and the security evaluation environment; including, method.
3. In Paragraph 2, The above security evaluation environment is, An operation to check the firmware version of the plurality of control devices above; An operation to request the latest version of firmware from a pre-designated server in a Hardware-in-the-Loop (HILS) test environment in which the plurality of control devices perform communication within a virtual vehicle environment; and An operation to update firmware by obtaining an update package for installing the latest version of firmware from the aforementioned pre-specified server through the aforementioned HILS test environment; This is being performed, method.
4. In Paragraph 3, The above security evaluation environment is, It includes a third security evaluation tool that performs an attack on at least one of a plurality of operations in which a wireless software update is performed, and The above third security evaluation tool is, Scenario 1, which involves setting up a fake server to distribute malicious updates, Scenario 2 for downgrading the updated firmware, A third scenario of inserting malicious code into an update package for installing the latest version of the firmware mentioned above, A fourth scenario for intercepting communication between the plurality of control devices and the HILS test environment, or communication between the HILS test environment and the predetermined server, Scenario 5, which causes unnecessary updates to be performed, Scenario 6, inserting malicious code into the cache area for performing an update, Scenario 7, attempting administrator access to the update system, Scenario 8, inserting malicious code into the update installation process A ninth scenario for stealing the key used for encryption or signing of the above update package and 10th scenario in which manipulation of the above update package is performed to induce the installation of an incompatible update including at least one of, method.
5. In Paragraph 4, The step of performing the security evaluation method using at least one of the first security evaluation tool, the second security evaluation tool, and the security evaluation environment is: A step of performing a wireless software update in the above-mentioned security evaluation environment; A step of injecting at least one scenario using the third security evaluation tool while the above wireless software update is being performed; and A step of transmitting the result of performing the above wireless software update and the result of injecting the above at least one scenario to the above-mentioned pre-specified server; including, method.
6. In Paragraph 1, The step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool is: Step of extracting a message list from a CAN DB file; A step of generating at least one test case using the messages included in the extracted message list; A step of injecting a first test case among the above at least one test case into a target control device constituting the vehicle internal network; A step of performing an analysis of whether there is an abnormality in the target control device following the injection of the first test case; and A step of performing a security evaluation method using the first security evaluation tool by determining whether to inject a second test case among the at least one test case based on whether there is an abnormality in the target control device; including, method.
7. A computer program stored on a computer-readable storage medium, wherein, when executed on one or more processors, the computer program performs a method for evaluating the security of an internal vehicle network, and the method comprises: A step of establishing a first security evaluation tool for performing a security evaluation method of an internal network in which communication between multiple control devices is performed - the first security evaluation tool is a tool for evaluating security regarding unknown vulnerabilities - ; Step of constructing a second security evaluation tool for performing the above security evaluation method - the second security evaluation tool is a tool for performing an evaluation of whether there is a possibility of attack - ; and A step of performing the security evaluation method using at least one of the first security evaluation tool and the second security evaluation tool; including, A computer program stored on a computer-readable storage medium.