Communication device and recovery method of communication device

Abstract

To restore a device to a normal state.SOLUTION: A compatibility list storage unit 11 stores a compatibility list representing a list in which identification information of programs used in other embedded devices 10 is associated with identification information of the other embedded devices 10 connected to an embedded device 10 via a communication network. A program storage unit 12 stores a target program used in the embedded device 10. An identification unit 13 uses the compatibility list to identify the other embedded devices 10 that use the same program as the target program. An acquisition unit 14 acquires the same program from the identified other embedded devices 10. A control unit 15 initializes a storage area for the target program in the program storage unit 12 and controls storage of the acquired same program in the initialized storage area.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to information processing technology. [Background technology]

[0002] There are known techniques for preventing the execution of unauthorized programs using a safe list (white list) (see, for example, Patent Documents 1 and 2). In addition, there are known techniques for restoring tampered programs or data to their original, correct versions (see, for example, Patent Documents 3 to 5). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2022-2373 [Patent Document 2] JP 2010-238168 A [Patent Document 3] JP 2006-178934 A [Patent Document 4] JP 2022-133461 A [Patent Document 5] JP 2020-177502 A Summary of the Invention [Problem to be solved by the invention]

[0004] Safelist-based security measures use lists to distinguish between legitimate programs and malicious objects (malware), treating legitimate programs as executable and malware as prohibited. However, if the malware itself that has been prohibited from execution remains in the memory of the device, not only will it waste memory, but the device may also malfunction due to the malware infecting (mixing) legitimate programs. [Means for solving the problem]

[0005] In one embodiment, the communication device includes a compatibility list storage unit, a program storage unit, an identification unit, an acquisition unit, and a control unit. The compatibility list storage unit stores a compatibility list that is a list that associates identification information of other communication devices connected to the communication device via a communication network with identification information of programs used in the other communication devices. The program storage unit stores a target program used in the communication device. The identification unit identifies other communication devices that use the same program as the target program using the compatibility list. The acquisition unit acquires the same program from the identified other communication devices. The control unit initializes a storage area for the target program in the program storage unit, and controls storage of the acquired same program in the initialized storage area. Effect of the Invention

[0006] According to the above aspect, it is possible to restore the device to a normal state. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates a configuration of an embedded device as an example of an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of information about the embedded device itself. [Diagram 3] FIG. 13 is a diagram illustrating an example of a safe list. [Figure 4] 1 is a diagram illustrating an example of a type of connection configuration of an embedded device to a communication network. [Diagram 5] FIG. 13 is a diagram showing an example of a matching list. [Figure 6] FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device. [Figure 7] 13 is a flowchart showing an example of a target program execution process; [Figure 8] 13 is a flowchart showing a process of an example of an object execution determining process. [Figure 9] 13 is a flowchart showing an example of an object determination process; [Figure 10] 13 is a flowchart illustrating an example of a recovery process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Malware infection can sometimes extend to software stored in non-volatile memory. In many cases, it is effective to remove malware from a device by resetting the device to its factory settings, but in some cases, it may not be possible to remove the malware, for example, if the malware has invaded the storage area of ​​the factory settings.

[0009] As a method for removing malware from a device, it is extremely effective to initialize the memory in the device in which a program infected with malware is stored, and then store a legitimate program that is not infected with malware in the initialized memory. However, if a new backup memory is provided in the device to back up the legitimate program in the device, the cost of the device increases. In addition, the possibility that this backup program is infected with malware cannot be denied.

[0010] In the embodiment described below, a communication device connected to a communication network holds a program compatibility list. The program compatibility list is a list showing, for each of other communication devices connected to the communication network, information on programs and safe lists held by the other communication devices, and information on the connection configuration of the other communication devices to the communication network.

[0011] When a communication device recognizes that a program it uses is suspected of being infected with malware, it uses the program compatibility list to identify other communication devices whose connection configuration to its communication network is compatible with the program and safe list it uses. Furthermore, the communication device initializes its own memory that has stored the program it uses, and obtains the same program as the program from the other identified communication device via the communication network and stores it in the initialized memory.

[0012] By doing the above, the state of the programs stored in the memory of the communication device itself is restored to the state before the malware infection, and the communication device is restored to a normal state. In addition, since the programs to be stored in the memory after initialization are obtained from other communication devices, a dedicated memory for backup is not required, and the increase in the cost of the communication device is suppressed.

[0013] Hereinafter, the embodiments will be described in detail with reference to the drawings.

[0014] First, a description will be given of Fig. 1. Fig. 1 is a diagram showing a configuration of an embedded device 10 as an example of an embodiment. The embedded device 10 is an example of a communication device connected to a communication network.

[0015] The embedded device 10 includes a compatibility list storage unit 11, a program storage unit 12, an identification unit 13, an acquisition unit 14, a control unit 15, and a safe list storage unit 16.

[0016] The compatibility list storage unit 11 stores a compatibility list. The compatibility list is a list that associates identification information of other communication devices connected to the embedded device 10 via a communication network with identification information of programs used in the other communication devices. For example, when multiple embedded devices 10 are connected to a communication network, the remaining embedded devices 10 excluding the embedded device itself from the multiple embedded devices 10 become "other communication devices." This will be described in detail later.

[0017] The program storage unit 12 stores a target program. The target program is a program to be used in the embedded device 10, which is the device itself.

[0018] The identification unit 13 identifies, from among the remaining embedded devices 10 connected to the communication network, embedded devices 10 that use the same program as the target program, using the compatibility list stored in the compatibility list memory unit 11.

[0019] The acquisition unit 14 acquires a program identical to the target program from the embedded device 10 identified by the identification unit 13.

[0020] The control unit 15 initializes a storage area for the target program in the program storage unit 12, and controls the program storage unit 12 to store the same program acquired by the acquisition unit 14 in the initialized storage area.

[0021] According to the embedded device 10 having the above-described configuration, even if the target program stored in the program memory unit 12 is infected with malware, the state of the target program is returned to the state before infection by the above-described control, and the target program is restored to a normal state.

[0022] The safe list storage unit 16 stores a safe list that indicates information about programs that are permitted to be executed in the embedded device 10 itself.

[0023] Details will be described later, but in this embodiment, the safe list is a list that associates identification information of each object that constitutes a program that is permitted to be executed in the embedded device 10, which is the device itself, with a hash value of the program code for each object.

[0024] The control unit 15 performs the above-mentioned control, for example, when a suspected malware infection is detected for a target program stored in the program storage unit 12. To achieve this, for example, the control unit 15 reads out program code for each object constituting the target program from the program storage unit 12, and calculates a hash value from the program code for each read object. The control unit 15 performs the above-mentioned control when any of the hash values ​​calculated for each read object does not match the hash values ​​associated with each object in the safe list.

[0025] The embedded device 10 shown in FIG. 1 includes the above-mentioned components.

[0026] Next, the own information and safe list of the embedded device 10 in this embodiment will be described. Fig. 2 shows an example of the own information of each embedded device 10, and Fig. 3 shows an example of the safe list.

[0027] "Ver 03" and "SL3_Ver1" shown in Fig. 2 are the management numbers of the program and the safe list, respectively, and are examples of the identification information of the program and the safe list. In other words, the example in Fig. 2 indicates that the program "Ver 03" and the safe list "SL3_Ver1" are used by the embedded device 10, which is the device itself.

[0028] As shown in Figure 3, each safelist is assigned the above-mentioned management number. Each line in the safelist corresponds to an object that constitutes a program, and information about that object is shown. The "No." item is a number that is conveniently assigned to identify each line in the safelist.

[0029] The "Object Name" field in each line of the safelist is the name given to each object that constitutes a program, which is an example of object identification information. The "Hash Code" field is the hash value of the program code for the object identified by the object name. Note that any hash function may be used to calculate this hash value, such as the widely known SHA-1, SHA-256, or MD5.

[0030] The safe list "SL3_Ver1" shown in Fig. 3 indicates the hash values ​​for each object, "Object XX", "Object ZZ", .... There is a one-to-one relationship between the programs used in the embedded device 10 and the safe list, and the safe list "SL3_Ver1" indicates the hash values ​​for all objects constituting the program "Ver 03". Therefore, the embedded device 10, whose own device is the information shown in Fig. 2, can use the safe list "SL3_Ver1" to determine whether or not the program "Ver 03" used by the embedded device is suspected of being infected with malware.

[0031] Also, in FIG. 2, "Pattern 3" is information on the network configuration, that is, information indicating the type of connection configuration of the embedded device 10 itself to the communication network.

[0032] The types of connection configurations of the embedded device 10 to the communication network will be described with reference to the example of FIG.

[0033] The system shown in Fig. 4 includes a hierarchical communication network having, in hierarchical order from top to bottom, an external LAN / public line 21, an internal LAN 22, an industrial network (type A) 23, and an industrial network (type B) 24. This system is configured so that embedded devices 10 can communicate with a cloud / server 20 or with other embedded devices 10 via the communication network, or further via other embedded devices 10 other than the embedded device itself. Note that "LAN" is an abbreviation for Local Area Network.

[0034] In the following explanation, it is assumed that TCP / IP is used as a communication protocol in the external LAN / public line 21 and the internal LAN 22. It is also assumed that Modbus is used as a communication protocol in the industrial network (type A) 23, and I2C is used as a communication protocol in the industrial network (type B) 24. Note that "TCP" is an abbreviation for Transmission Control Protocol, "IP" is an abbreviation for Internet Protocol, and "I2C" is an abbreviation for Inter-Integrated Circuit.

[0035] FIG. 4 shows five types, "Pattern 1" to "Pattern 5," as connection configurations to a communication network of the embedded device 10 that constitutes this system.

[0036] “Pattern 1” represents a connection configuration in which the upper side is connected to the internal LAN 22 and the lower side provides the industrial network (type A) 23 with the function of a parent station (master).

[0037] “Pattern 2” represents a connection configuration in which the upper side is connected to the internal LAN 22 .

[0038] “Pattern 3” represents a connection configuration in which the upper side provides the industrial network (type A) 23 with a function as a child station (slave), and the lower side provides the industrial network (type B) 24 with a function as a parent station.

[0039] "Pattern 4" represents a connection configuration in which the upper side provides a function as a slave station to the industrial network (type A) 23. Note that communication between the embedded devices 10 in "Pattern 4" is performed via the embedded device 10 that provides a function as a master station to the industrial network (type A) 23 (the embedded device 10 of "Pattern 1").

[0040] "Pattern 5" represents a connection configuration in which the upper side provides the industrial network (type B) 24 with the function of a slave station.

[0041] Note that communication between embedded devices 10 in "Pattern 3" and communication between embedded devices 10 in "Pattern 4" is performed via an embedded device 10 (embedded device 10 of "Pattern 1") that provides a function as a master station to the industrial network (Type A) 23. Communication between embedded devices 10 in "Pattern 5" is performed via an embedded device 10 (embedded device 10 of "Pattern 3") that provides a function as a master station to the industrial network (Type B) 24.

[0042] 2 shows that the embedded device 10 has a connection configuration to the communication network of "Pattern 3." Therefore, the embedded device 10 has a connection configuration in which the upper side provides the industrial network (type A) 23 with a function as a slave station, and the lower side provides the industrial network (type B) 24 with a function as a master station.

[0043] Next, the match list will be described. Figure 5 shows an example of the match list.

[0044] Each line of the compatibility list corresponds to a counterpart embedded device 10 with which the embedded device 10 communicates via a communication network, and indicates information about the counterpart embedded device 10. The "List No." item is a number that is given for convenience in order to identify each line of the application list.

[0045] The items "Program," "Safe List," and "Network Connection Configuration" in each row of the compatibility list are each information about the counterpart embedded device 10, and are the same information as the information shown in FIG.

[0046] The item "network protocol" is information on the communication protocol used for communication with the counterpart embedded device 10.

[0047] The "network connection destination" item is identification information of the counterpart embedded device 10 used when communicating with the counterpart embedded device 10 using the communication protocol shown in "network protocol".

[0048] This compatibility list is set, for example, by an installer when installing the embedded device 10 in a communication network, and is stored in the compatibility list storage unit 11 of the embedded device 10. Note that the embedded device 10 may be provided with a mechanism for causing an embedded device 10 that has completed installation in a communication network to make inquiries to other embedded devices 10 to collect various information about the other embedded devices 10, and for creating a compatibility list using the information obtained.

[0049] Next, the hardware configuration of the embedded device 10 will be described.

[0050] 6 shows an example of the hardware configuration of the information processing device 30. The embedded device 10 may be configured using this information processing device 30.

[0051] The information processing device 30 is a computer equipped with the following components: a CPU 31, a memory 32, an input device 33, a display device 34, an auxiliary storage device 35, and a communication I / F 36. All of these components are connected to an internal bus 37, and are configured to enable data to be exchanged between the components. Note that "CPU" is an abbreviation for Central Processing Unit. Also, "I / F" is an abbreviation for Interface.

[0052] The CPU 31 controls each component of the information processing device 30, for example, by executing a predetermined program using the memory 32, thereby enabling the provision of the functions of the identification unit 13, the acquisition unit 14, and the control unit 15 in the configuration of the embedded device 10 in Figure 1.

[0053] The input device 33 is, for example, a keyboard or a pointing device for inputting instructions.

[0054] The display device 34 is used, for example, to display and output various types of information.

[0055] The auxiliary storage device 35 is a non-volatile storage device, such as a flash memory, and provides the functions of the compatibility list storage unit 11, the program storage unit 12, and the safe list storage unit 16 in the configuration of the embedded device 10 in FIG.

[0056] The communication I / F 36 transmits and receives various data to and from the cloud / server 20 or other embedded devices 10 via a communication network in accordance with instructions sent from the CPU 31.

[0057] When configuring the embedded device 10 using the information processing device 30, the information processing device 30 does not need to include all of the components shown in FIG. 5, and some components may be omitted depending on the application or conditions.

[0058] Next, a description will be given of a target program execution process performed by the embedded device 10. Fig. 7 is a flowchart showing the processing contents of an example of the target program execution process.

[0059] The target program execution process is basically a process of executing the target program, but in addition, it also determines whether or not there is a suspicion of malware infection in the target program, and if it determines that there is a suspicion, it also performs a process of restoring the target program in the embedded device 10 to a normal state.

[0060] When configuring the embedded device 10 using the information processing device 30 in Fig. 6, a target program execution program describing the processing contents of the target program execution process is created and stored in the auxiliary storage device 35. Then, a predetermined instruction is given to the CPU 31 to read the target program execution program from the auxiliary storage device 35 and execute it.

[0061] When the target program execution process of FIG. 7 is started, first, in S101, a process of acquiring the first object in the execution order from the target program read from its own program storage unit 12 is performed.

[0062] Next, in S102, an object execution determination process is performed on the object acquired by the most recently executed process. This object execution determination process is a process for determining whether or not the object is suspected of being infected with malware, and for executing the object if it is determined that there is no such suspicion. The details of this process will be described later.

[0063] Next, in S103, a process is performed to determine whether or not the next object in the execution order following the object obtained by the most recently executed process exists in the target program read from the program storage unit 12. In this determination process, when it is determined that the next object in the execution order exists in the target program (when the determination result is YES), the process proceeds to S104. On the other hand, in this determination process, when it is determined that the next object in the execution order does not exist in the target program anymore (when the determination result is NO), the process proceeds to S105.

[0064] In S104, a process is performed to obtain the object that is the first object in the execution order following the object obtained by the most recently executed process from the target program read from the program storage unit 12. After this process, the process returns to S102, and an object execution determination process is performed on the object obtained by the process of S104.

[0065] In S105, a process is performed to determine whether the recovery request flag is set to "On."

[0066] The recovery request flag is a flag that requests the embedded device 10 to be restored to a normal state when a suspicion of malware infection is detected in any of the objects that constitute the target program read from the program storage unit 12 by executing the process of S103. The recovery request flag is set to "Off" in the initial state, and is set to "On" when a suspicion of malware infection is detected.

[0067] When it is determined in the determination process of S105 that the recovery request flag is set to "On" (when the determination result is YES), the process proceeds to S106, and the recovery process of S106 is performed.

[0068] The recovery process is a process of initializing the program storage unit 12 in which a target program including an object suspected of being infected by malware has been stored, and acquiring a legitimate target program from another embedded device 10 and storing it in the initialized program storage unit 12. Details of this recovery process will be described later.

[0069] When it is determined in the determination process of S105 that the recovery request flag is set to "Off" (when the determination result is NO), the process returns to S101 and the execution of the various processes described above is restarted.

[0070] The above-mentioned processing is the target program execution processing shown in FIG.

[0071] Next, details of the object execution determining process, which is the process of S102 in Fig. 7, will be described with reference to Fig. 8. Fig. 8 is a flowchart showing the contents of an example of the object execution determining process.

[0072] In FIG. 8, first, in S111, a process of reading and acquiring the safe list from its own safe list storage unit 16 is performed.

[0073] Next, in S112, an object determination process is performed. The object determination process is a process for determining whether or not an object to be processed by the ongoing object execution determination process is suspected of being infected with malware, and thereby determining whether or not the object can be executed. The details of this process will be described later.

[0074] In S113, a process is performed to determine whether the object to be processed is not suspected of being infected with malware and whether execution of the object is permitted (whether execution is OK) by the object determination process in S112. If it is determined in this determination process that execution is OK (if the determination result is YES), the process proceeds to S114, where the object to be processed is executed. On the other hand, if it is determined in this determination process that execution is not OK (if the determination result is NO), the process proceeds to S115, where the above-mentioned recovery request flag is set to "On" and execution of the object to be processed is suspended.

[0075] Thereafter, when the process of S114 or S115 is completed, the object execution determination process is completed, and the process returns to the target program execution process of FIG. 7, where the process of S103 is performed.

[0076] The above-mentioned processing is the object execution determination processing shown in FIG.

[0077] Next, details of the object determination process which is the process of S112 in Fig. 8 will be described with reference to Fig. 9. Fig. 9 is a flowchart showing the process contents of an example of the object determination process.

[0078] 9, first, in S121, a process is performed in which the safe list acquired in the process of S111 in Fig. 8 is searched for an object name for an object to be processed by the object execution process currently being executed. Then, in the following S122, a process is performed to determine whether the object name exists. In this determination process, if it is determined that the object name exists (if the determination result is YES), the process proceeds to S123. On the other hand, in this determination process, if it is determined that the object name does not exist (if the determination result is NO), the process proceeds to S127.

[0079] In S123, a process of calculating a hash value for the program code of the object to be processed by the object execution process being executed is performed.

[0080] Next, in S124, a process is performed to confirm whether the hash value calculated in the process of S123 matches a hash value associated with the object name of the object to be processed in the safe list acquired in the process of S111 of Fig. 8. Then, as a result of this confirmation, a process is performed in the following S125 to determine whether the two hash values ​​match.

[0081] In the judgment process of S125, if it is judged that the two hash values ​​match (if the judgment result is YES), it is judged that the object to be processed is not suspected of being infected with malware. In this case, in S126, the return value of the object execution judgment process is set to "object execution OK".

[0082] On the other hand, if it is determined in the determination process of S125 that the two hash values ​​do not match (if the determination result is NO), it is determined that the object to be processed is suspected of being infected with malware. In this case, in S127, a process is performed in which the return value of the object execution determination process is set to "object execution pending." Note that the same process is also performed in S127 when the result of the determination process of S122 described above is NO.

[0083] When the process of S126 or S127 described above is completed, the object execution process ends, and thereafter the process returns to the object execution determination process of FIG. 8, where in S113 a determination process is made based on the return value of the object execution process.

[0084] The above-mentioned processing is the object execution processing shown in FIG.

[0085] Next, details of the recovery process which is the process of S106 in the target program execution process of Fig. 7 will be described with reference to Fig. 10. Fig. 10 is a flowchart showing the process contents of an example of the recovery process.

[0086] 10, first, in S141, a process is performed in which another embedded device 10 compatible with the own device is searched for in the compatibility list stored in the compatibility list storage unit 11 by referring to the compatibility list. Then, in the following S142, a process is performed in which it is determined whether or not there is an embedded device 10 compatible with the own device among the embedded devices 10 shown in the compatibility list, i.e., among the embedded devices 10 with which the own device can communicate via the communication network.

[0087] An embedded device 10 compatible with the own device is an embedded device 10 that uses the same program as the target program used in the own device, i.e., the embedded device 10 that is indicated in the compatibility list as using the same program as the target program used in the own device is the embedded device 10 that is compatible with the own device. For example, in the compatibility list of FIG. 5, the embedded device 10 with list No. "3" in which the program management number is the same as the program management number "Ver 03" in the information of the own device shown in FIG. 2 is determined to be the embedded device 10 that is compatible with the own device. Note that an embedded device 10 in which the program management number in the compatibility list is a version (i.e., "Ver 02") earlier than the program version indicated by the program management number in the information of the own device may also be treated as compatible with the own device.

[0088] In addition, as a criterion for determining whether an embedded device 10 is compatible with the own device, in addition to the same program, either or both of the same safe list and the same network connection configuration may be added.

[0089] In the determination process of S142, if it is determined that another compatible embedded device 10 exists (if the determination result is YES), the process proceeds to S143. On the other hand, if it is determined that another compatible embedded device 10 does not exist (if the determination result is NO), the recovery process is terminated and the process returns to the target program execution process of FIG.

[0090] In the process from S143 to S150, communication is performed between the embedded device 10 itself and another embedded device 10 that is identified as being compatible with the embedded device itself using the compatibility list. In this communication, the network protocol and the network connection destination shown in the compatibility list as information about the other embedded device 10 are used as the communication protocol and the identification information of the other embedded device 10, respectively.

[0091] In S143, an inquiry is made to other embedded devices 10 that are compatible with the own device and whose existence has been confirmed and identified from the compatibility list, as to whether the target program can be provided. Then, in the following S144, a response to the inquiry is received.

[0092] The target program is also stored in the program storage unit 12 of another embedded device 10 connected to the embedded device 10 via a communication network. The other embedded device 10 can also execute the object determination process described above, and can determine whether or not the objects constituting the target program are suspected of being infected with malware by using the compatibility list stored in its own compatibility list storage unit 11. In other words, the process of S143 can be said to be a process of inquiring of the other embedded device 10 identified using the compatibility list as to whether or not the program used in the other embedded device 10 is suspected of being infected with malware.

[0093] The other embedded device 10 that has received the inquiry in the process of S143 executes an object determination process for each object constituting the target program stored in its own program storage unit 12. If the result of this execution indicates that any object is determined to be suspected of being infected with malware, the other embedded device 10 responds to the inquiring embedded device 10 that it is unable to provide the target program. On the other hand, if it is determined that all objects are not suspected of being infected with malware, the other embedded device 10 responds to the inquiring embedded device 10 that it is able to provide the target program, as a response indicating this determination result.

[0094] In S145, a process is performed to determine whether the answer received in the process of S144 was able to provide the target program. In this determination process, if it is determined that the answer was able to provide the target program (if the determination result is YES), the process proceeds to S147. On the other hand, in this determination process, if it is determined that the answer was not able to provide the target program (if the determination result is NO), the process proceeds to S146.

[0095] In S146, a process is performed to determine whether or not there remains any embedded device 10 that is compatible with the own device and whose existence has been confirmed from the compatibility list and that has not been queried in the process of S143. If it is determined in this determination process that there remains another embedded device 10 that has not been queried (if the determination result is YES), the process returns to S143 and queries are processed for the other embedded devices 10 that have not been queried. On the other hand, if it is determined in this determination process that there remains no embedded device 10 that has not been queried (if the determination result is NO), the recovery process is terminated and the process returns to the target program execution process of FIG. 7.

[0096] In S147, a process is performed to initialize the storage area of ​​the program storage unit 12 in which the target program including the object determined to be suspected of being infected with malware is stored.

[0097] In S148, a process is performed to transmit a request to send the target program to the embedded device 10 that has responded that the target program can be provided. In response to the request, the embedded device 10 transmits the legitimate target program that has been confirmed to be free of malware infection.

[0098] In S149, a process is performed in which the regular target program transmitted from the embedded device 10 that received the sending request transmitted in the process of S148 is received and acquired.

[0099] In S150, a process is performed in which the regular target program acquired in the process of S149 is written and stored in the storage area of ​​the program storage unit 12 initialized in the process of S147. After completion of this process, the recovery process is terminated, and the process returns to the target program execution process in FIG.

[0100] The above processing is the recovery processing shown in FIG.

[0101] Although the disclosed embodiments and their advantages have been described in detail above, it will be appreciated that those skilled in the art may make various modifications, additions, and omissions therein without departing from the scope of the present invention as clearly set forth in the claims.

[0102] For example, in the recovery process of FIG. 10, in the judgment process of S142, as described above, the sameness of the network connection configuration may be added to the sameness of the program as the judgment criteria for another embedded device 10 that is compatible with the embedded device 10 that is the own device. If this judgment criterion is adopted, it becomes possible to prioritize the embedded device 10 that has the same network connection configuration in the selection of the inquiry destination in the inquiry performed when the process is returned from S146 to S143. It is expected that the embedded device 10 that has the same network connection configuration will require less time to exchange data with the embedded device 10 that is the own device than the embedded device 10 that has a different connection configuration. In addition, since the program used in the embedded device 10 that has the same network connection configuration has the same settings related to the network connection configuration as the own device, it can be used in the own device as it is without changing the settings. In addition, when the own device receives the program, it is not necessary to also receive information on the network connection configuration of the embedded device 10 that provides the program. Therefore, the time required to receive data from the embedded device 10 that provides the program is reduced. Furthermore, if a program used in an embedded device 10 that has a track record of being operated in the same network connection configuration is used in one's own device, one can expect network quality equivalent to that of the embedded device 10. This reduces the risk of communication problems caused by the program (for example, increased delays in communication or an increase in the number of retries). [Explanation of symbols]

[0103] 10 Embedded Devices 11 Matching list storage section 12 Program memory section 13 Specific section 14 Acquisition Department 15 Control section 16 Safelist storage 20 Cloud / Server 21 External LAN / Public Line 22 Internal LAN 23 Industrial Network (Type A) 24 Industrial Network (Type B) 30 Information processing device 31 CPU 32 Memory 33 Input Devices 34 Display device 35 Auxiliary storage device 36 Communication I / F 37 Internal Bus

Claims

1. A communication device, a compatibility list storage unit that stores a compatibility list that is a list in which identification information of another communication device connected to the communication device via a communication network is associated with identification information of the program used in the other communication device; a program storage unit that stores a target program to be used in the communication device; an identification unit that identifies the other communication devices using the compatibility list, the other communication devices using the same program as the target program; an acquisition unit that acquires the same program from the identified other communication device; a control unit that initializes a storage area of ​​the target program in the program storage unit and controls the same program that has been acquired to be stored in the initialized storage area; A communication device comprising:

2. The communication device according to claim 1 , wherein the control unit performs the control when a suspicion of malware infection is detected for the target program stored in the program storage unit.

3. a safe list storage unit that stores a safe list indicating information of a program permitted to be executed in the communication device, the safe list being a list in which identification information of each object constituting the program is associated with a hash value of a program code for each object; The control unit is reading out from the program storage unit program code for each object constituting the target program; Calculating a hash value from the program code for each object that has been read; performing the control when the hash value calculated for each read object does not match the hash value associated with the object in the safe list; 3. The communication device according to claim 2.

4. In the compatibility list, information indicating a type of a connection configuration of the other communication device to the communication network is further associated with identification information of the other communication device, the identifying unit identifies, by using the compatibility list, the other communication device that uses the same program as the target program and has the same type of connection configuration to the communication network as the communication device; 2. The communication device according to claim 1 .

5. In the compatibility list, the identification information of the safe list for the other communication device is further associated with the identification information of the other communication device, The identification unit identifies the other communication devices that use the same program as the target program and that use the same safe list as the communication device, using the compatibility list.

4. The communication device according to claim 3.

6. The communication device according to claim 1, characterized in that the acquisition unit inquires of the identified other communication device as to whether or not the same program used in the other communication device is suspected of being infected with malware, and acquires the same program from the other communication device that responds that there is no suspicion of infection.

7. using a compatibility list that associates identification information of other communication devices connected to the communication device via a communication network with identification information of the program used in the other communication devices, the other communication devices using a target program that is the same as the target program used in the communication device and that is stored in a program storage unit provided in the communication device; Obtaining the same program from the identified other communication device; initializing a storage area of ​​the target program in the program storage unit and controlling the same program acquired to be stored in the initialized storage area; A method for recovering a communication device comprising the steps of:

Images