Security measures method and security measures system

Abstract

In this security measure method for software executed in a vehicle, the software is composed of a plurality of first modules, and the vehicle is provided with a ROM for holding a plurality of second modules corresponding to respective first modules, confirms the presence or absence of an abnormality in each of the first modules, extracts an abnormal first module from the software when an abnormal first module is detected, reads the second module corresponding to the abnormal first module from the ROM, and rewrites the abnormal first module in the software to the second module read from the ROM.

Description

[Technical field]

[0001] The present disclosure relates to a security countermeasure method and a security countermeasure system. [Background technology]

[0002] In recent years, vehicles (e.g., connected cars) that can download and update data and software for, for example, realizing driving assistance or autonomous driving through an external communication network are known. Such vehicles may be subject to cyber attacks using malware, viruses, and the like through the external communication network. If subjected to a cyber attack, for example, software or data may be tampered with, and unauthorized control commands may be executed, causing the vehicle to malfunction. For this reason, vehicles that can be connected to a communication network are required to have sufficient security measures (e.g., Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-119090 Summary of the Invention [Problem to be solved by the invention]

[0004] Vehicle security measures must ensure that the vehicle remains safe even if a virus invades the vehicle.

[0005] An object of the present disclosure is to provide a security countermeasure method and a security countermeasure system that can sufficiently ensure the safety of vehicle driving even if a virus invades. [Means for solving the problem]

[0006] A security countermeasure method according to one embodiment of the present disclosure is a security countermeasure method for software executed in a vehicle, wherein the software is composed of a plurality of first modules, and the vehicle is equipped with a ROM (Read Only Memory) that holds a plurality of second modules corresponding to the plurality of first modules, and the vehicle checks whether or not there is an abnormality in each of the plurality of first modules, and if an abnormal first module is detected, extracts the abnormal first module from the software, reads from the ROM the second module corresponding to the abnormal first module, and rewrites the abnormal first module in the software with the second module read from the ROM.

[0007] A security countermeasure system according to one embodiment of the present disclosure is a security countermeasure system that performs security countermeasures for software executed in a vehicle, and includes a server and a vehicle, the software being composed of a plurality of first modules, the vehicle being equipped with a ROM that holds a plurality of second modules that respectively correspond to the plurality of first modules, the vehicle checking for an abnormality in each of the plurality of first modules, and if an abnormal first module is detected, deleting the abnormal first module from the software, reading from the ROM the second module that corresponds to the abnormal first module, and rewriting the abnormal first module in the software with the second module read from the ROM.

[0008] Furthermore, these comprehensive or specific aspects may be realized by a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, or may be realized by any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium. Effect of the Invention

[0009] According to the present disclosure, it is possible to provide a security countermeasure method and a security countermeasure system that can sufficiently ensure the safety of vehicle driving even if a virus invades. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram showing a configuration example of a security countermeasure system according to an embodiment of the present invention. [Diagram 2] A flowchart showing an example of a process performed by a virus check unit of a vehicle according to the present embodiment. [Diagram 3] FIG. 1 is a diagram showing an example of a software structure according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, the embodiments of the present disclosure will be described in detail with reference to the drawings as appropriate. However, more detailed description than necessary may be omitted. For example, detailed description of already well-known matters and duplicated description of substantially the same configuration may be omitted. This is to avoid the following description becoming unnecessarily redundant and to facilitate understanding by those skilled in the art. Note that the accompanying drawings and the following description are provided to enable those skilled in the art to fully understand the present disclosure, and are not intended to limit the subject matter described in the claims.

[0012] (Present embodiment) <System configuration> FIG. 1 is a block diagram showing an example of the configuration of a security countermeasure system 1 according to the present embodiment.

[0013] The security countermeasure system 1 is a system for implementing security countermeasures for software 50 executed by a vehicle 20. As shown in FIG. 1, the security countermeasure system 1 includes a server 10 and a vehicle 20. The server 10 and the vehicle 20 can transmit and receive information to each other via a communication network 3. An example of the communication network 3 is a cellular network. (LTE (Long Term Evolution), 4G, 5G, etc.), Wi-Fi (registered trademark), or the Internet.

[0014] The vehicle 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The control unit 21, the storage unit 22, and the communication unit 23 may be mounted on the vehicle 20 as an ECU (Electronic Control Unit).

[0015] The control unit 21 executes software 50 for implementing functions of the vehicle 20. The software 50 may be interpreted as a computer program. The control unit 21 may be interpreted as other terms such as a processor, a CPU (Central Processing Unit), a controller, or an LSI (Large Scale Integrated Circuit). Details of the functions implemented by the control unit 21 will be described later.

[0016] The storage unit 22 holds software 50 and data executed by the control unit 21. The storage unit 22 includes a read only memory (ROM) 31 and a random access memory (RAM) 32. The ROM 31 is made up of a non-volatile storage medium. The RAM 32 is made up of a volatile storage medium. However, the RAM 32 may also be made up of a non-volatile storage medium.

[0017] The communication unit 23 controls wireless communication through the communication network 3. For example, the communication unit 23 transmits and receives information by wireless signals.

[0018] The control unit 21 has, as its functions, a virus detection and removal unit 41, a software module unit 42, and a virus check unit 43. In the following description, processing mainly performed by the virus detection and removal unit 41, the software module unit 42, or the virus check unit 43 can be read as processing mainly performed by the control unit 21.

[0019] The virus detection and removal unit 41 performs virus detection on the software 50 and data received through the communication unit 23. For example, the virus detection and removal unit 41 detects a virus 5 by comparing it with a virus pattern stored therein. Furthermore, when the virus detection and removal unit 41 detects a virus 5, it removes the detected virus 5. Note that the virus pattern may be interpreted as other terms such as a virus definition file or a vaccine.

[0020] The software module unit 42 executes software 50 configured by a plurality of modules. The software 50 may perform, for example, driving assistance control or automatic driving control of the vehicle 20. Hereinafter, each module configuring the software 50 executed by the software module unit 42 is referred to as a first module 51. In this embodiment, as shown in FIG. 1, the software 50 will be described as being configured by first modules 51A to 51F. In this case, the software module unit 42 may realize the function provided by the software 50 by repeatedly executing a process of sequentially processing the first module 51A, the first module 51B, ..., the first module 51F, and then returning to the process of the first module 51A.

[0021] The virus check unit 43 checks whether or not there is an abnormality in each of the first modules 51 constituting the software 50. For example, the virus check unit 43 may check whether or not there is a possibility that each of the first modules 51 is infected with a virus. Details of the process performed by the virus check unit 43 will be described later.

[0022] The ROM 31 stores in advance second modules 61A to 61F corresponding to the first modules 51A to 51F constituting the software 50, respectively. The second modules 61A to 61F may be the same as the first modules 51A to 51F. Alternatively, the second modules 61A to 61F may be older versions than the first modules 51A to 51F but may achieve the same functions. The second modules 61A to 61F in the ROM 31 may be non-rewritable. This prevents the second modules 61A to 61F from being rewritten by external cyber attacks. In this embodiment, when the second modules 61A to 61F are not to be distinguished from each other, they are referred to as the second modules 61.

[0023] The server 10 performs tasks such as analyzing new viruses, generating and updating virus patterns, and distributing virus patterns to each vehicle 20. The server 10 may be configured as one unit or multiple units. The server 10 may also be interpreted as a so-called cloud service that provides various services to the vehicles 20 via the communication network 3.

[0024] Next, with reference to FIG. 1, a security countermeasure method by the security countermeasure system 1 according to the present embodiment will be described in detail.

[0025] First, the process of distributing the software 50 to each vehicle 20 will be described.

[0026] The server 10 distributes the software 50 to each vehicle 20 through the communication network 3 (S11).

[0027] The communication unit 23 of the vehicle 20 receives the software 50 in step S11, and provides it to the virus detection and removal unit 41 (S12).

[0028] The virus detection and removal unit 41 performs virus detection on the software 50 provided in step S12 using the currently stored virus pattern. If no virus is detected, the virus detection and removal unit 41 provides the software 50 to the software module unit 42 (S13).

[0029] Next, a process in which the virus check unit 43 of the vehicle 20 checks for any abnormality in the software 50 will be described.

[0030] The virus check unit 43 checks whether there is an abnormality in each of the first modules 51A to 51F constituting the software 50 executed by the software module unit 42. For example, as shown in Fig. 1, it is assumed that a virus 5 is a new virus 5 not registered in a virus pattern, is not detected by the virus detection and removal unit 41, and has invaded the first module 51B. In this case, the virus check unit 43 determines as a result of the check that there is an abnormality in the first module 51B, and executes the following process.

[0031] The virus check unit 43 extracts the first module 51B from the software 50 (S21).

[0032] The virus check unit 43 obtains the second module 61B corresponding to the first module 51B from the ROM 31 (S22).

[0033] The virus check unit 43 rewrites the first module 51B in the software 50 to the second module 61B acquired in step S22 (S23). This allows the first module 51B, which has an abnormality due to, for example, a virus infection, to be quickly rewritten to the normal second module 61B. For example, by rewriting to the second module 61B before the first module 51B is executed, the normal second module 61B is executed instead of the virus-infected first module 51B. This allows the safety of the vehicle 20 during travel to be sufficiently ensured.

[0034] The virus check unit 43 transmits the first module 51B extracted in step S21 to the server 10 via the communication unit 23 (S24, S25).

[0035] The server 10 judges whether the received first module 51B is infected with the new virus 5. If the server 10 judges that the first module 51B is infected with the new virus 5, it updates the virus pattern so as to deal with the new virus 5. The server 10 distributes the updated virus pattern to each vehicle 20 via the communication network 3 (S26). Note that if the server 10 judges that the abnormality in the first module 51B is, for example, simple data corruption and not due to infection by the new virus 5, it is not necessary to update the virus pattern.

[0036] The communication unit 23 of the vehicle 20 receives the virus pattern distributed in step S26 and provides it to the virus detection and removal unit 41 (S27). The virus detection and removal unit 41 updates the virus pattern it holds to the provided virus pattern, thereby making it possible to detect and remove a similar new virus 5 in the future. That is, the virus detection and removal unit 41 will not allow a similar new virus 5 to invade the software module unit 42. In addition, since the updated virus pattern is distributed to the other vehicles 20, the other vehicles 20 will also not allow a similar new virus 5 to invade the software module unit 42. That is, according to this embodiment, when one vehicle 20 is infected with a new virus 5, a virus pattern capable of detecting the new virus 5 can be quickly distributed to the other vehicles 20. This makes it possible to prevent the infection of the new virus 5 from spreading.

[0037] <Virus check processing> FIG. 2 is a flowchart showing an example of processing by the virus check unit 43 of the vehicle 20 according to the present embodiment.

[0038] The virus check unit 43 selects one of the multiple first modules 51 constituting the software 50 as a target for virus check (S101). In the explanation of FIG. 2, the selected first module 51 is referred to as the target first module 51. For example, the virus check unit 43 selects the first modules 51A to 51F shown in FIG. 1 in order as the target first module 51. After selecting the first module 51F, the virus check unit 43 may select the first module 51A as the target first module 51.

[0039] The virus check unit 43 judges whether the target first module 51 is abnormal (S102). For example, when the output value from the target first module 51 is within the normal range, the virus check unit 43 outputs a bit "1" indicating that the target first module 51 is normal, and when the output value from the target first module 51 is outside the normal range, the virus check unit 43 outputs a bit "0" indicating that the target first module 51 is abnormal. For example, when the hash value of the target first module 51 matches a hash value calculated in advance in a normal state (i.e., there is no trace of rewriting), the virus check unit 43 outputs a bit "1" indicating that the target first module 51 is normal, and when the hash value of the target first module 51 does not match a hash value calculated in advance in a normal state (i.e., there is trace of rewriting), the virus check unit 43 outputs a bit "0" indicating that the target first module 51 is abnormal. Note that the bits "1" and "0" may be reversed.

[0040] If the target first module 51 is normal (that is, if the output of step S102 is the bit "1") (S102: NO), the virus checker 43 returns the process to S101.

[0041] If the target first module 51 is abnormal (i.e., if the output of step S102 is bit "0") (S102: YES), the virus check unit 43 extracts the target first module 51 from the software 50 (S103). Note that the virus check unit 43 may delete the target first module 51 from the software 50 immediately after extracting the target first module 51.

[0042] The virus check unit 43 acquires the second module 61 corresponding to the target first module 51 from the ROM 31 (S104).

[0043] The virus check unit 43 rewrites the target first module 51 in the software 50 with the second module 61 acquired in step S104 (S105). For example, the virus check unit 43 deletes the first module 51B from the software 50 and writes the second module 61B instead.

[0044] The virus check unit 43 transmits the target first module 51 extracted in step S103 to the server 10 (S106), and returns the process to step S101.

[0045] According to the above process, the vehicle 20 can quickly rewrite (replace) an abnormal (e.g., virus-infected) first module 51 with a corresponding normal (e.g., virus-free) second module 61. Furthermore, the vehicle 20 can transmit the first module 51 possibly infected with a virus to the server 10. This allows the server 10 to create and distribute a virus pattern capable of detecting a new virus, as described above.

[0046] <Software structure> FIG. 3 is a diagram for explaining the structure of software 50 according to the present embodiment.

[0047] Generally, the designer of the software 50 constructs the software 50 with a smaller number of modules from the viewpoint of reducing data size, increasing processing speed, etc. However, in this embodiment, the software 50 is constructed with a larger number of modules. Note that the term "module" may be replaced with other terms such as a process or a thread.

[0048] For example, software 50 related to autonomous driving control is generally constructed by a sensing control module 71 that controls sensing of the surrounding conditions of the vehicle 20 using a sensor (e.g., LiDAR (Light Detection And Ranging) or a camera) mounted on the vehicle 20, and a behavior control module 72 that controls the behavior of the vehicle 20 based on the output results from the sensing control module 71, as shown in FIG. 3(a).

[0049] 3(b), the function corresponding to the sensing control module 71 is divided into a forward sensing control module 81 that controls sensing of the situation in front of the vehicle 20 by a sensor mounted on the front of the vehicle 20, and a side sensing control module 82 that controls sensing of the situation on the side of the vehicle 20 by a sensor mounted on the side of the vehicle 20. Furthermore, the function corresponding to the behavior control module 72 is divided into a steering control module 83 that controls the steering of the vehicle 20 based on the output results from the forward sensing control module 81 and the side sensing control module 82, and a speed control module 84 that controls the speed of the vehicle 20 based on the output results from the forward sensing control module 81 and the side sensing control module 82 and the output result from the steering control module 83.

[0050] This prevents the side sensing control module 82 from being affected by a virus from affecting the forward sensing control module 81. That is, as shown in this embodiment, by intentionally constructing the software 50 with a larger number of modules, even if one module is infected with a virus, the extent of the effect can be kept to a minimum.

[0051] In addition, as shown in this embodiment, by intentionally constructing the software 50 with a larger number of modules, the probability that the first module 51 is being executed when the first module 51 is rewritten in S103 to S105 in Fig. 2 is reduced. Therefore, even if one first module 51 is infected with a virus, the virus-infected first module 51 is more likely to be replaced with the corresponding second module 61 in the ROM 31 before being executed. In other words, the probability that the virus-infected first module 51 is executed is reduced, and the safety of the running of the vehicle 20 can be sufficiently ensured.

[0052] Summary of the Disclosure The contents of the present disclosure can be expressed as follows:

[0053] <Appendix 1> In a security countermeasure method for software (50) executed in a vehicle (20), the software is composed of a plurality of first modules (51). The vehicle includes a ROM (31) that holds a plurality of second modules (61) that respectively correspond to the plurality of first modules. The vehicle checks whether or not there is an abnormality in each of the plurality of first modules, and when an abnormal first module is detected, extracts the abnormal first module from the software, reads out from the ROM a second module that corresponds to the abnormal first module, and rewrites the abnormal first module in the software with the second module read out from the ROM. This makes it possible to rewrite an abnormal first module, which may be infected with a virus, into a normal second module in the ROM, thereby ensuring sufficient safety during vehicle operation.

[0054] <Appendix 2> In the security countermeasure method described in Appendix 2, the vehicle transmits the abnormal first module to a predetermined server (10). The server may perform a virus analysis on the abnormal first module, and if a virus is detected, generate a virus pattern for detecting the virus (5). This allows the server to quickly generate a virus pattern that can detect the new virus if the anomaly in the first module is due to infection with a new virus.

[0055] <Appendix 3> In the security countermeasure method described in Appendix 2, the server distributes the generated virus pattern to each vehicle, and each vehicle uses the virus pattern distributed from the server to perform virus detection for newly received software. As a result, if one vehicle is infected with a new virus, a virus pattern capable of detecting the new virus can be quickly distributed to other vehicles, thereby preventing the spread of infection by the new virus 5.

[0056] <Appendix 4> A security countermeasure system (1) that implements security countermeasures for software (50) executed in a vehicle (20) includes a server (10) and the vehicle. The software (50) is composed of a plurality of first modules (51). The vehicle is equipped with a ROM (31) that holds a plurality of second modules (61) that respectively correspond to the plurality of first modules. The vehicle checks whether or not there is an abnormality in each of the plurality of first modules, and when an abnormal first module is detected, extracts the abnormal first module from the software, reads out from the ROM a second module that corresponds to the abnormal first module, and rewrites the abnormal first module in the software with the second module read out from the ROM. This makes it possible to rewrite an abnormal first module, which may be infected with a virus, into a normal second module in the ROM, thereby ensuring sufficient safety during vehicle operation.

[0057] <Appendix 5> In the security countermeasure system described in Supplementary Note 4, the vehicle transmits the abnormal first module to the server. The server performs a virus analysis on the abnormal first module, and if a virus (5) is detected, generates a virus pattern for detecting the virus. This allows the server to quickly generate a virus pattern that can detect the new virus if the anomaly in the first module is due to infection with a new virus.

[0058] <Appendix 6> In the security countermeasure system described in Supplementary Note 5, the server transmits the generated virus pattern to each vehicle. Each vehicle uses the virus pattern received from the server to perform virus detection for newly received software. As a result, if one vehicle is infected with a new virus, a virus pattern capable of detecting the new virus can be quickly distributed to other vehicles, thereby preventing the spread of infection by the new virus 5.

[0059] Although the embodiments have been described above with reference to the accompanying drawings, the present disclosure is not limited to such examples. It is clear that a person skilled in the art can conceive of various modifications, corrections, substitutions, additions, deletions, and equivalents within the scope of the claims, and it is understood that these also belong to the technical scope of the present disclosure. In addition, the components in the above-mentioned embodiments may be arbitrarily combined within the scope of the invention.

[0060] This application is based on a Japanese patent application (Patent Application No. 2021-205291) filed on December 17, 2021, the contents of which are incorporated by reference into this application. [Industrial Applicability]

[0061] The technology disclosed herein is useful for software security measures. [Explanation of symbols]

[0062] 1. Security system 3. Communication Network 5. Viruses 10 Server 20 Vehicles 21 Control section 22 Memory section 23 Communications Department 31 ROM 32 RAM 41 Virus detection and removal section 42 Software Module Section 43 Virus Check Department 50 Software 51, 51A, 51B, 51C, 51D, 51E, 51F 1st module 61, 61A, 61B, 61C, 61D, 61E, 61F Second Module 71 Sensing control module 72 Behavior Control Module 81 Forward Sensing Control Module 82 Side sensing control module 83 Steering control module 84 Speed ​​Control Module

Claims

1. A method for security measures for software executed in a vehicle, comprising: The software is composed of a plurality of first modules, the vehicle includes a ROM (Read Only Memory) that holds a plurality of second modules that respectively correspond to the plurality of first modules; The vehicle is checking whether or not there is an abnormality in each of the plurality of first modules; if an abnormal first module is detected, extracting the abnormal first module from the software; reading the second module corresponding to the abnormal first module from the ROM; rewriting the abnormal first module in the software with the second module read from the ROM; The vehicle further transmits the abnormal first module to a predetermined server; the server performs a virus analysis on the abnormal first module, and if a virus is detected, generates a virus pattern for detecting the virus; Security measures.

2. The server distributes the generated virus pattern to each vehicle, each of the vehicles performs virus detection for newly received software by using the virus pattern distributed from the server; The security countermeasure method according to claim 1.

3. A security countermeasure system for performing security countermeasures for software executed in a vehicle, comprising: a server and a vehicle; The software is composed of a plurality of first modules, the vehicle includes a ROM that holds a plurality of second modules that respectively correspond to the plurality of first modules; The vehicle is checking whether or not there is an abnormality in each of the plurality of first modules; if an abnormal first module is detected, removing the abnormal first module from the software; reading the second module corresponding to the abnormal first module from the ROM; rewriting the abnormal first module in the software with the second module read from the ROM; The vehicle further transmits the abnormal first module to the server; the server performs a virus analysis on the abnormal first module, and if a virus is detected, generates a virus pattern for detecting the virus; Security measures system.

4. The server transmits the generated virus pattern to each vehicle, each of the vehicles performs virus detection for newly received software by using the virus pattern received from the server; The security system according to claim 3 .

Images