Monitoring range determination device, monitoring range determination method, and program

Abstract

The present disclosure relates to a monitoring range determination device (200) that determines, for software to be monitored, the monitoring range of a falsification detection feature call function (hook) that is inserted together with a falsification detection feature. The monitoring range determination device (200) comprises a CFG generation unit (201) that generates a CFG on the basis of the binary of the software, and a monitoring range determination unit (202). The monitoring range determination unit (202) uses the CFG to determine a provisional insertion point at which each hook is inserted into the source code of the software, uses the CFG to determine a provisional monitoring range of the hook for which the provisional insertion point has been determined according to a predetermined rule, sequentially selects the hook for which the provisional insertion point has been determined, adds a node to the determined provisional monitoring range of the selected hook on the basis of an allowable processing delay set in advance, and determines, as the monitoring range of the selected hook, a monitoring range obtained by adding the node to the determined provisional monitoring range of the selected hook.

Description

[Technical field]

[0001] The present disclosure relates to a monitoring range determination device, a monitoring range determination method, and a computer-readable medium that determine the monitoring range to be monitored by a tamper detection function call function that calls a tamper detection function, and in particular to a monitoring range determination device, a monitoring range determination method, and a computer-readable medium used in software for devices such as IoT (Internet of Things) devices. [Background technology]

[0002] In recent years, IoT devices have become widespread. Accordingly, there is a demand for security systems that can operate on devices that do not have abundant resources such as memory and central processing units (CPUs).

[0003] A related security system is known in which a whitelist-based tamper detection function using hash values ​​is built into equipment, and the software on the equipment is monitored to see if it is in the correct state (if it has not been tampered with).

[0004] The whitelist-type tamper detection function using hash values ​​is a function that registers the memory information of a device under normal conditions in a whitelist in advance, compares the memory information of the device in operation with the memory information registered in the whitelist, and monitors for tampering. At this time, the memory information is managed in the form of a hash value.

[0005] A whitelist-type tamper detection function using hash values ​​is implemented as follows. First, memory information of the device under normal conditions is obtained in advance by some method, and the obtained memory information is registered in a whitelist. The memory information is information that indicates how executable code is deployed in memory. Next, memory information is obtained at any time while the device is operating, and the obtained memory information is compared with the memory information registered in the whitelist. If the comparison shows that the memory information obtained while the device is operating matches the memory information registered in the whitelist, it means that there has been no tampering (no attack), and if they do not match, it means that the device has been tampered with (is under attack).

[0006] The whitelist is a snapshot of memory under normal conditions. However, registering and comparing memory snapshots in the form of hash values ​​has less impact on the device's original operation than registering and comparing them in their original form. Therefore, the whitelist registers memory information under normal conditions in the form of hash values, and memory information during operation is also managed in the form of hash values. An example of a whitelist-type tamper detection function using hash values ​​is disclosed in Non-Patent Documents 1 and 2.

[0007] Non-Patent Document 1 discloses a method in which an input to a device is used as a trigger to detect tampering with the next function to be executed. According to the method of Non-Patent Document 1, the next function to be executed (here, referred to as function A) is determined by the user's input. In addition, the user's input activates a tampering detection function calling function that calls the tampering detection function. The tampering detection function calling function calls the tampering detection function, limits the memory area used when executing function A to a monitoring range, and monitors whether or not the monitoring range has been tampered with.

[0008] Non-Patent Document 2 discloses a method that aims to achieve faster monitoring than the method of Non-Patent Document 1 by treating the monitoring range in one monitoring as one node of a control flow graph (CFG). Here, a CFG is a graph showing the order in which a program is executed. Therefore, a CFG is a directed graph. A node of a CFG becomes the execution code of a succession of programs. At this time, one node of a CFG is divided into blocks for each branch instruction, and these blocks are called basic blocks. In other words, one node of a CFG is one basic block.

[0009] Here, examples of source code and CFG will be described with reference to Fig. 1. The right side of Fig. 1 shows source code, and the left side of Fig. 1 shows CFG generated based on a binary built from the source code on the right side. Also, the numbers in each node on the left side of Fig. 1 indicate the line numbers of the source code on the right side, and each node indicates that it contains execution code corresponding to the line numbers indicated by the numbers in each node. For example, node 2 contains execution code corresponding to lines 6 and 7 of the source code.

[0010] Further, examples of source code and CFG in which a tamper detection function calling function (hereinafter referred to as "hook" where appropriate) is embedded will be described with reference to Figures 2 and 3. Figure 2 shows source code in which a hook is embedded in the source code of Figure 1, and Figure 3 shows a CFG generated based on a binary built from the source code of Figure 2. In the examples of Figures 2 and 3, hook H1 is embedded immediately before node 1, and the monitoring range of hook H1 is nodes 1 and 3. Furthermore, hooks H2, H4, H5, and H6 are embedded immediately before nodes 2, 4, 5, and 6, respectively, and the monitoring range of hooks H2, H4, H5, and H6 is nodes 2, 4, 5, and 6, respectively. In the examples of Figures 2 and 3, hooks H1, H2, H4, H5, and H6 are incorporated as independent nodes immediately before nodes 1, 2, 4, 5, and 6, respectively, but they may also be incorporated at the beginning of nodes 1, 2, 4, 5, and 6, or in the middle of nodes 1, 2, 4, 5, and 6. [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] Toshiki Kobayashi, Takayuki Sasaki, Astha Jada, Daniele E. Asoni, Adrian Perrig, “SAFES: Sand-boxed Architecture for Frequent Environment Self-measurement”, Proceedings of the 3rd Workshop on System Software for Trusted Execution, 2018, pp. 37-41. [Non-Patent Document 2] Yuto Hayaki, Takayuki Sasaki, Senpei Ryu, Mitsuteru Tomita, Norio Yamagaki, "Proposal of a Proof-of-Trust Technology Using Tamper Detection Function for IoT Devices," SCIS2020, 2020, pp.1-6 Summary of the Invention [Problem to be solved by the invention]

[0012] As described above, the whitelist registers memory information in the form of hash values. In detail, the whitelist registers, for each hook, a set of the hook ID, the monitoring range of the hook, and the hash value of the monitoring range.

[0013] Therefore, as the number of monitoring ranges increases, the size of the whitelist also increases. For example, when one hook monitors one node (basic block) at a time, the size of the whitelist is maximum. The size of the whitelist in this case is whitelist is expressed by the following Equation 1.

number

[0014] In formula 1, Num basic block is the number of nodes (basic blocks). Also, identifier is the size of the hook ID. Also, Addr start is the size of the start address of the monitoring range, and Addr end is the size of the end address of the monitoring range. Also, hashvalue is the size of the hash value of the monitoring range (32 bytes for SHA-256). Note that in formula 1, the monitoring range is expressed as a pair of a start address and an end address, but the monitoring range may also be expressed as a pair of a start address and an address range (the range from the start address to the end address). In that case, formula 1 can be calculated by replacing the size of the end address of the monitoring range with the size of the address range of the monitoring range. Also, of the parameters in parentheses in formula 1, the largest size is the hash value.

[0015] Here, the size of the whitelist can be reduced by consolidating the monitoring ranges. The size of the whitelist when consolidating the monitoring ranges is whitelist is expressed by the following Equation 2.

number

[0016] In formula 2, Num check is the number of monitoring ranges. Formula 2 reduces the number of hook IDs and the number of large-sized hash values ​​compared to Formula 1. Therefore, the size of the whitelist calculated by Formula 2 is smaller than the size of the whitelist calculated by Formula 1.

[0017] For example, if there are 10 nodes (basic blocks) in the CFG and one hook monitors one node (basic block), the size of the whitelist is whitelist According to the formula 1, it is expressed by the following formula 3.

number

[0018] On the other hand, if there are 10 nodes (basic blocks) on the CFG, and two nodes (basic blocks) are grouped together and one hook monitors two nodes (basic blocks), the size of the whitelist is whitelist According to the formula 2, it is expressed by the following formula 4.

number

[0019] In this way, by consolidating monitoring scopes, it is possible to reduce the size of the whitelist. However, simply consolidating the monitoring ranges and reducing the size of the whitelist may result in increased processing delays in the tamper detection process.

[0020] Therefore, an object of the present disclosure is to provide a monitoring range determination device, a monitoring range determination method, and a computer-readable medium that can determine the monitoring range of a tamper detection function call function so as to reduce the size of the whitelist while keeping the processing delay of the tamper detection process within an appropriate range. [Means for solving the problem]

[0021] A monitoring range determination device according to one aspect of the present disclosure includes: A monitoring range determination device that determines a monitoring range of a tamper detection function calling function that is incorporated together with a tamper detection function for software to be monitored, comprising: A CFG generator that generates a control flow graph (CFG) based on the binary of the software; A monitoring range determination unit, The monitoring range determination unit is provisionally determining, based on the CFG, an embedding location for embedding the tamper detection function call function in the source code of the software, and provisionally determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function call function whose embedding location has been provisionally determined; Sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined, adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; The monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function is determined as the monitoring range of the selected tamper detection function calling function.

[0022] A monitoring range determination method according to another aspect of the present disclosure includes: A monitoring range determination method executed by a monitoring range determination device that determines a monitoring range of a tamper detection function calling function that is incorporated together with a tamper detection function in software to be monitored, comprising the steps of: generating a control flow graph (CFG) based on the software binary; provisionally determining, based on the CFG, an embedding location for embedding the tamper detection function calling function in the source code of the software, and provisionally determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function calling function, the embedding location of which has been provisionally determined; a step of sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined; adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; and determining a monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function as the monitoring range of the selected tamper detection function calling function.

[0023] According to yet another aspect of the present disclosure, there is provided a computer readable medium comprising: A non-transitory computer-readable medium storing a program for causing a computer to execute a process for determining a monitoring range of a tamper detection function calling function incorporated together with a tamper detection function for software to be monitored, The program is generating a control flow graph (CFG) based on the software binary; provisionally determining, based on the CFG, an embedding location for embedding the tamper detection function calling function in the source code of the software, and provisionally determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function calling function, the embedding location of which has been provisionally determined; a step of sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined; adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; and determining a monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function as the monitoring range of the selected tamper detection function calling function. Effect of the Invention

[0024] According to the above-mentioned aspects, it is possible to provide a monitoring range determination device, a monitoring range determination method, and a computer-readable medium that can determine the monitoring range of a tamper detection function call function so as to reduce the size of the whitelist while keeping the processing delay of the tamper detection process within an appropriate range. [Brief description of the drawings]

[0025] [Figure 1] FIG. 13 is a diagram illustrating an example of source code and a CFG. [Diagram 2] 2 is a diagram showing an example of source code in which a tamper detection function calling function is incorporated into the source code of FIG. 1; FIG. [Diagram 3] FIG. 3 is a diagram showing an example of a CFG generated based on the source code of FIG. 2. [Figure 4] 1 is a block diagram showing a configuration example of a monitoring range determination device according to a first embodiment. [Diagram 5] A figure explaining a specific example of a method by which the whitelist creation unit in embodiment 1 determines the location of a hook to be incorporated and the monitoring range of the hook. [Figure 6] 11 is a diagram for explaining an example of a predetermined policy used by the whitelist creation unit according to the first embodiment when determining the monitoring range of a hook. FIG. [Figure 7] 4 is a flowchart illustrating an example of the overall operation of the monitoring range determination device according to the first embodiment. [Figure 8] 8 is a flowchart illustrating an example of an operation performed by a whitelist creating unit according to the first embodiment in step A4 of FIG. 7. [Figure 9] 9 is a flowchart illustrating an example of an operation performed by a whitelist creating unit according to the first embodiment in step B4 of FIG. 8. [Figure 10] 11 is a diagram showing an example of hook insertion locations and monitoring ranges (monitoring nodes) provisionally determined by a whitelist creation unit in the first embodiment. FIG. [Figure 11] 11 is a block diagram showing a configuration example of a monitoring range determination device according to a second embodiment. FIG. [Figure 12] 11 is a block diagram showing an example of a hardware configuration of a monitoring range determination device according to a third embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. In the following embodiments, the same or equivalent elements are given the same reference numerals, and duplicated descriptions are omitted. The monitoring range determination device described in each of the following embodiments is an example of a device that determines the monitoring range of a tamper detection function call function (hook) that is incorporated into software to be monitored together with a whitelist-type tamper detection function using a hash value.

[0027] [Embodiment 1] [Configuration of the first embodiment] First, a configuration example of the monitoring range determination device 100 according to the first embodiment will be described with reference to Fig. 4. Note that in Fig. 4, the unidirectional arrows simply indicate the direction of flow of certain data (or signals, information, etc.) and do not exclude bidirectionality.

[0028] Referring to FIG. 4, the monitoring range determination device 100 according to the first embodiment includes an input / output unit 101, a build unit 102, a Control Flow Graph (CFG) generation unit 103, a whitelist creation unit 104, and a memory unit 105.

[0029] These components operate as follows: The source code of the software to be monitored, that is, the software into which a tamper detection function is to be incorporated, is input to the input / output unit 101. The software to be monitored is, for example, control software on an IoT device. The input / output unit 101 stores the input source code in the storage unit 105, and notifies the build unit 102 to perform processing.

[0030] Furthermore, when the input / output unit 101 receives a notification from the whitelist creation unit 104, as described below, it reads out the binary of the software incorporating the tampering detection function and hooks described below (hereinafter referred to as the "tampering detection function-embedded binary") from the memory unit 105, and outputs the read out tampering detection function-embedded binary. Furthermore, the input / output unit 101 reads out the whitelist described below from the memory unit 105, and outputs the read out whitelist together with the tampering detection function-embedded binary. However, the input / output unit 101 is not limited to reading out the tampering detection function-embedded binary and the whitelist from the memory unit 105. The input / output unit 101 may receive the tampering detection function-embedded binary from the build unit 102, or may receive the whitelist from the whitelist creation unit 104.

[0031] When the build unit 102 receives the notification from the input / output unit 101, it reads the source code from the storage unit 105 and performs a build. The build unit 102 stores the binary generated by the build in the storage unit 105 and sends a notification to the CFG generation unit 103 to perform processing.

[0032] Furthermore, when the build unit 102 receives a notification from the whitelist creation unit 104, the build unit 102 reads source code incorporating a tampering detection function and a hook (to be described later) from the storage unit 105 and builds it. The build unit 102 stores the tampering detection function-embedded binary generated by the build in the storage unit 105.

[0033] Upon receiving the notification from the build unit 102, the CFG generation unit 103 reads the binary from the storage unit 105, analyzes the read binary, and generates a CFG. The CFG generation unit 103 sends the CFG generated from the binary to the whitelist creation unit 104.

[0034] When the whitelist creation unit 104 receives a CFG from the CFG generation unit 103, it determines, based on the CFG, for each hook to be incorporated into the source code, the location in the source code where the hook is to be incorporated, and also determines the monitoring range of the hook.

[0035] The whitelist creation unit 104 also incorporates the hooks into the source code at the embedding locations determined above, and also incorporates the tampering detection function into the source code. The set of source code into which the hooks and the tampering detection function are thus embedded is the tampering detection function embedded source code. The whitelist creation unit 104 stores the tampering detection function embedded source code in the storage unit 105. After storing the tampering detection function embedded source code in the storage unit 105, the whitelist creation unit 104 sends a notification to the build unit 102 to perform processing.

[0036] Furthermore, the whitelist creation unit 104 creates a whitelist in which, for each hook, a set of the ID of the hook, the monitoring range of the hook, and the hash value of the monitoring range is registered, and stores the created whitelist in the memory unit 105. Furthermore, after storing the whitelist in the memory unit 105, the whitelist creation unit 104 sends a notification to the input / output unit 101 to perform processing.

[0037] The memory unit 105 stores the source code received from the input / output unit 101, the whitelist and source code with built-in tamper detection function received from the whitelist creation unit 104, and the binaries and binaries with built-in tamper detection function received from the build unit 102.

[0038] The storage unit 105 is not an essential component of the monitoring range determination device 100, and may be provided outside the monitoring range determination device 100. In other words, the monitoring range determination device 100 may be realized with a minimum configuration including an input / output unit 101, a build unit 102, a CFG generation unit 103, and a whitelist creation unit 104.

[0039] Next, an overview of a method for determining the hook embedding location and the monitoring range of the hook in the whitelist creating unit 104 will be described.

[0040] In the tamper detection process, the allowable processing delay that is allowed when the hook performs one monitoring is set in advance. Based on this, the whitelist creation unit 104 determines the monitoring range of the hook. Note that the processing delay of the tamper detection process includes processing delays due to memory read and hash value calculation, but the memory read time and hash value calculation time can be estimated from past history, etc.

[0041] First, the whitelist creation unit 104 provisionally determines the location where a hook is to be incorporated based on the CFG, and also provisionally determines the monitoring range of the hook whose location has been provisionally determined based on the CFG and in accordance with a predetermined rule (step 1).

[0042] For example, the predetermined rule may be a rule that adds a node including the hook to the monitoring range of the hook. For example, in the examples of Figures 2 and 3, if the hook is hook H1, the node including hook H1 is node 1. Therefore, the whitelist creation unit 104 adds node 1 including hook H1 to the monitoring range of hook H1.

[0043] Alternatively, the predetermined rule may be a rule that, among all descendant nodes of the node including the hook, the nodes that do not include a hook are traced, and the nodes from the node including the hook to the node immediately preceding the node including the next hook are added to the monitoring range of the hook. For example, in the examples of Figs. 2 and 3, if the hook is hook H1, the node that includes hook H1 is node 1. Also, among the descendant nodes of node 1, the node that does not include a hook is node 3. Therefore, the whitelist creation unit 104 traces node 3, but nodes 4 and 5, which are child nodes of node 3, include hooks H4 and H5, respectively. Therefore, the whitelist creation unit 104 adds node 1, which includes hook H1, and node 3 to the monitoring range of hook H1.

[0044] Next, the whitelist creation unit 104 sequentially selects the hooks whose embedding locations have been provisionally determined, and adds another monitoring range (node) to the provisionally determined monitoring range of the selected hook based on a preset allowable processing delay. In detail, the whitelist creation unit 104 compares the size of the provisionally determined monitoring range of the selected hook with a size derived from a preset allowable processing delay (hereinafter referred to as a "threshold size"). If the size of the provisionally determined monitoring range of the hook is equal to or smaller than the threshold size, the whitelist creation unit 104 adds another monitoring range (node) to the provisionally determined monitoring range of the hook in accordance with a predetermined policy so that the size of the monitoring range does not exceed the threshold size. Then, the whitelist creation unit 104 determines the monitoring range of the hook after the other monitoring range (node) is added to the provisionally determined monitoring range of the hook. The whitelist creation unit 104 also determines to delete the hook that was provisionally determined to monitor the other monitoring range (node) (step 2).

[0045] Here, with reference to FIG. 5, a specific example of a method for determining the hook embedding location and the monitoring range of the hook in the whitelist creating unit 104 will be described. In FIG. 5, the upper part shows a provisionally determined monitoring range, and the lower part shows a finally determined monitoring range. In the upper part of FIG. 5, monitors 1 to 4 respectively indicate provisionally determined monitor ranges of hooks H1 to H4, for example, and processes 1 to 4 respectively indicate processes performed by software.

[0046] 5, the size of the provisionally determined monitoring range of hook H2 is equal to or smaller than the threshold size derived from the allowable processing delay. Even if the provisionally determined monitoring range of hook H3 is added to the provisionally determined monitoring range of hook H2, the total size of the monitoring range after the addition is equal to or smaller than the threshold size.

[0047] Therefore, as shown in the lower part of Fig. 5, the whitelist creation unit 104 adds the provisionally determined monitoring range of hook H3 to the provisionally determined monitoring range of hook H2, and determines the monitoring range after addition as the monitoring range of hook H2. Accordingly, the whitelist creation unit 104 determines to delete hook H3. In this way, by consolidating the monitoring ranges so as not to exceed the threshold size derived from the allowable processing delay, it is possible to prevent the processing delay of the tampering detection process from increasing beyond the allowable processing delay while reducing the size of the whitelist.

[0048] Next, an example of a predetermined policy used when the whitelist creating unit 104 determines the monitoring range of a hook will be described below with reference to FIG. The specified policy is that for a certain hook, the hook will monitor the next node that may be executed after the tentatively determined monitoring range, and the hook will avoid monitoring nodes that are branched off from the tentatively determined monitoring range and may not be executed as much as possible.

[0049] The whitelist creating unit 104 determines the hook monitoring range in accordance with the following priorities in order to comply with the above-mentioned predetermined policy. 1st priority (high): For a certain hook, if there is a conditional branch from the provisionally determined monitoring range, one of the nodes at the branch destination is always executed next. Therefore, when there is a conditional branch from the provisionally determined monitoring range for a certain hook, the whitelist creation unit 104 adds all nodes of the branch destination to the provisionally determined monitoring range. This increases the ratio of nodes of the branch destination, i.e., the ratio of nodes that may be executed next, in the provisionally determined monitoring range.

[0050] 2nd priority (low): For a certain hook, if there is no conditional branch from the provisionally determined monitoring range, the subsequent nodes are always executed. Therefore, when there is no conditional branch from the provisionally determined monitoring range for a certain hook, the whitelist creating unit 104 adds all subsequent nodes to the provisionally determined monitoring range.

[0051] 6 shows an example of determining the monitoring range of a hook embedded immediately before node A. Here, it is assumed that the provisionally determined monitoring range of the hook is node A. Also, node A has a conditional branch.

[0052] In this case, the whitelist creation unit 104 adds all the branching nodes B and E to the provisionally determined monitoring range (node ​​A) of the hook according to the first priority. In this case, although the effect of reducing the size of the whitelist is small, the number of areas where monitoring is wasted is small, and the number of monitoring times is reduced.

[0053] However, when nodes B and E are added to the provisionally determined monitoring range (node ​​A) of the hook, the total size of the monitoring range after the addition may exceed the threshold size. Here, the size of node B is smaller than the size of node E, and when nodes B and E are added to the provisionally determined monitoring range (node ​​A), the total size of the monitoring range after the addition exceeds the threshold size, but it is assumed that the total size is equal to or smaller than the threshold size when only node B is added. Also, nodes B to D do not have conditional branches.

[0054] In this case, the whitelist creation unit 104 adds not only the branching destination node B to the provisionally determined monitoring range (node ​​A) of the hook according to the second priority, but also nodes C and D one by one if the threshold size is not exceeded. In this case, if a branch is made from node A to node E, the area where monitoring is wasted increases, but the effect of reducing the size of the whitelist is large.

[0055] [Operation of the first embodiment] Next, an example of the overall operation of the monitoring range determining device 100 according to the first embodiment will be described with reference to a flowchart of FIG.

[0056] 7, first, the source code of the software to be monitored is input to the input / output unit 101. The input / output unit 101 stores the input source code in the storage unit 105, and notifies the build unit 102 to perform processing (step A1).

[0057] When the build unit 102 receives the notification from the input / output unit 101, it reads the source code input in step A1 from the storage unit 105, builds the read source code, and generates a binary. The build unit 102 stores the generated binary in the storage unit 105, and sends a notification to the CFG generation unit 103 to perform processing (step A2).

[0058] Upon receiving the notification from the build unit 102, the CFG generation unit 103 reads the binary generated in step A2 from the storage unit 105, analyzes the read binary, and generates a CFG. Furthermore, the CFG generation unit 103 sends the generated CFG to the whitelist creation unit 104 (step A3).

[0059] When the whitelist creation unit 104 receives the CFG generated in step A3 from the CFG generation unit 103, it determines, for each hook to be incorporated in the source code, an incorporation location in the source code where the hook is to be incorporated, based on the received CFG, and also determines a monitoring range for the hook (step A4). Details of step A4 will be described later.

[0060] Furthermore, the whitelist creation unit 104 incorporates a hook into the source code incorporation location determined above, and also incorporates a tampering detection function into the source code. As a result, the whitelist creation unit 104 generates tampering detection function-embedded source code that incorporates a hook and a tampering detection function. The whitelist creation unit 104 stores the tampering detection function-embedded source code in the storage unit 105 (step A5). Furthermore, when the processing of step A5 ends, the whitelist creation unit 104 sends a notification to the build unit 102 to perform processing.

[0061] When the build unit 102 receives the notification from the whitelist creation unit 104, it reads the tampering detection function-embedded source code generated in step A5 from the storage unit 105, builds the read tampering detection function-embedded source code, and generates a tampering detection function-embedded binary. The build unit 102 stores the generated tampering detection function-embedded binary in the storage unit 105 (step A6).

[0062] Furthermore, the whitelist creation unit 104 creates a whitelist in which a set of the hook ID, the monitoring range of the hook, and the hash value of the monitoring range is registered for each hook, and stores the created whitelist in the memory unit 105 (step A7). Furthermore, when the processing of step A7 is completed, the whitelist creation unit 104 sends a notification to the input / output unit 101 to perform processing.

[0063] When the input / output unit 101 receives a notification from the whitelist creation unit 104, it reads out the whitelist created in step A7 and the binary with embedded tamper detection function generated in step A6 from the memory unit 105, and outputs the read whitelist and the binary with embedded tamper detection function (step A8).

[0064] Next, the operation performed by the whitelist creating unit 104 in step A4 of FIG. 7 will be described in detail with reference to the flowchart of FIG.

[0065] Referring to Figure 8, first, for each hook to be incorporated into the source code, the whitelist creation unit 104 provisionally determines the location where the hook will be incorporated based on the CFG, and also provisionally determines the monitoring range of the hook based on the CFG and in accordance with specified rules (step B1).

[0066] Next, the whitelist creation unit 104 judges whether there are any unprocessed hooks (step B2). The unprocessed hooks are the hooks excluding the hooks whose monitoring ranges have been determined in the following step B4 and the hooks whose deletion has been determined.

[0067] In step B2, if there are unprocessed hooks (YES in step B2), the whitelist creating unit 104 selects one hook from the unprocessed hooks (step B3).

[0068] Next, the whitelist creation unit 104 determines the monitoring range of the hook selected in step B3 (step B4). Specifically, the whitelist creation unit 104 attempts to add a node to the monitoring range provisionally determined in step B1 for the hook so that the size of the monitoring range does not exceed the threshold size. If the node can be added, the whitelist creation unit 104 determines the monitoring range to which the node has been added as the monitoring range of the hook. On the other hand, if the node cannot be added, the whitelist creation unit 104 determines the monitoring range provisionally determined in step B1 as the monitoring range of the hook. When determining the monitoring range of each hook, it is not necessary to actually incorporate the hook into the binary, but if technically necessary, the hook may be incorporated once. Details of step B4 will be described later. Furthermore, if a node has been added to the monitoring range of the hook in step B4, the whitelist creation unit 104 determines to delete the hook provisionally determined to monitor the added node. Then, the process returns to step B2. As described above, the hooks for which the monitoring range has been determined in step B4 and the hooks for which deletion has been determined are not treated as unprocessed hooks in the subsequent step B2.

[0069] On the other hand, if there are no unprocessed hooks in step B2 (step B2 is NO), the whitelist creation unit 104 determines the incorporation location and monitoring range of each hook (step B5). Specifically, the whitelist creation unit 104 determines the incorporation location and monitoring range of each hook that was not deleted during the processes of steps B1 to B4. At this time, the whitelist creation unit 104 provisionally determines the incorporation location of each hook in step B1, and determines it to be the incorporation location that was not deleted in step B4. In addition, the whitelist creation unit 104 determines the monitoring range of each hook to be the monitoring range determined in step B4.

[0070] Next, the operation performed by the whitelist creation unit 104 in step B4 in FIG. 8 will be described in detail with reference to the flow chart in FIG. 9. Here, the nodes included in the monitoring range of each hook are regarded as a group of nodes, and are hereinafter referred to as a monitoring node. For example, similar to the examples in FIG. 2 and FIG. 3, when the embedding locations and monitoring ranges of each hook H1, H2, H4, H5, and H6 are provisionally determined, the monitoring nodes of each hook H1, H2, H4, H5, and H6 are as shown in FIG. 10. Note that when creating a monitoring node, it is not necessary to actually embed a hook on the binary, but if technically necessary, the hook may be embedded once. In addition, in the case of a normal node, if there is a conditional branch, there will be two child nodes, and if there is no conditional branch, there will be one child node, but there may be cases where the child nodes of a monitoring node are three or more.

[0071] 9, first, the whitelist creation unit 104 focuses on the provisionally determined monitoring node of the hook selected in step B3 of Fig. 8 (step C1). Note that the nodes included in the hook monitoring node are stored in the storage unit 105 at any timing, such as after the processing of step B1 of Fig. 8 is completed. In an example where hook H1 of Fig. 10 is selected as the hook, the monitoring nodes of hook H1 include nodes 1 and 3.

[0072] Next, the whitelist creating unit 104 judges whether or not the size of the monitoring node of the hook is equal to or smaller than a threshold size derived from a preset allowable processing delay (step C2).

[0073] In step C2, if the size of the monitoring node of the hook exceeds the threshold size (if step C2 is NO), the whitelist creation unit 104 determines the monitoring range of the hook to be the current monitoring node of the hook (step C9).

[0074] On the other hand, if the size of the monitoring node of the hook is equal to or smaller than the threshold size in step C2 (YES in step C2), the whitelist creation unit 104 judges whether or not the monitoring node of the hook has a child node (hereinafter, called a "candidate node") to which addition has not been attempted (step C3). In the example in which hook H1 in Fig. 10 is selected as the hook, the candidate nodes in the monitoring node of hook H1 are three, nodes 2, 4, and 5.

[0075] In step C3, if there is a candidate node for which no attempt has been made to add it to the monitoring node of the hook (step C3 is YES), the whitelist creation unit 104 adds all the candidate nodes for which no attempt has been made to add it to the monitoring node of the hook (step C4), and stores the added candidate nodes in the storage unit 105 (step C5). In an example in which hook H1 in Fig. 10 is selected as the hook, the whitelist creation unit 104 adds all nodes 2, 4, and 5 to the monitoring node of hook H1 if no attempt has been made to add the candidate nodes 2, 4, and 5.

[0076] Next, the whitelist creating unit 104 judges whether the total size after adding the candidate node to the monitoring node of the hook is equal to or smaller than the threshold size (step C6).

[0077] In step C6, if the total size of the monitoring nodes of the hook exceeds the threshold size (if step C6 is NO), the whitelist creation unit 104 removes the candidate node with the largest size among the candidate nodes added in step C4 from the monitoring nodes of the hook (step C7), and then returns to processing of step C6. On the other hand, in step C6, if the total size of the monitoring nodes of the hook is equal to or smaller than the threshold size (YES in step C6), the process returns to step C3.

[0078] That is, in steps C6 and C7, the whitelist creation unit 104 performs a process of removing the candidate nodes added in step C4 from the monitoring node of the hook in order of size until the total size of the monitoring node of the hook becomes equal to or smaller than the threshold size. In an example in which the hook H1 in Fig. 10 is selected as the hook, if nodes 2, 4, and 5 are added to the monitoring node of hook H1 in step C4, the whitelist creation unit 104 removes nodes 2, 4, and 5 from the monitoring node of hook H1 in order of size. As a result, in the monitoring node of hook H1, at least one of nodes 2, 4, and 5 remains added, or all of nodes 2, 4, and 5 are removed.

[0079] In step C3 after returning from step C6, if there is a node that has been added to the monitoring node of the hook, the whitelist creation unit 104 judges whether there is a candidate node that has not been added to the monitoring node of that state. In an example in which the hook H1 in Fig. 10 is selected as the hook, for example, if node 2 has been added to the monitoring node of hook H1, the new candidate node in the monitoring node of hook H1 will be node 6. Therefore, in the subsequent processing of steps C4 to C7, the whitelist creation unit 104 adds node 6 to the monitoring node of hook H1, and if the total size of the monitoring nodes of hook H1 is equal to or less than the threshold size, node 6 will remain added, and if it exceeds the threshold size, node 6 will be removed.

[0080] In step C3, if there is no candidate node that has not been attempted to be added to the monitoring node of the hook (NO in step C3), the whitelist creation unit 104 resets the candidate node that was removed from the monitoring node of the hook in step C7, and deletes it from the storage unit 105 (step C8). After that, the whitelist creation unit 104 determines the monitoring range of the hook to be the current monitoring node of the hook (step C9).

[0081] [Advantages of the first embodiment] Next, the effects of the monitoring range determining device 100 according to the first embodiment will be described. According to the first embodiment, the whitelist creation unit 104 provisionally determines the hook embedding location and the monitoring range of the hook based on the CFG. Next, the whitelist creation unit 104 sequentially selects the hooks whose embedding locations have been provisionally determined, and adds nodes to the provisionally determined monitoring range of the selected hook based on a preset allowable processing delay. After that, the whitelist creation unit 104 determines the monitoring range of the hook after the nodes are added to the provisionally determined monitoring range. This makes it possible to add nodes to the monitoring range of each hook while taking the allowable processing delay into consideration. Therefore, it is possible to combine the monitoring ranges to reduce the size of the whitelist, while preventing the processing delay of the tampering detection process from increasing beyond the allowable processing delay, and to determine the monitoring range of the hook so as to be within an appropriate range.

[0082] Furthermore, according to the first embodiment, the whitelist creation unit 104 selects nodes to be added to the provisionally determined monitoring range so that the proportion of nodes that may be executed next in the provisionally determined monitoring range is increased. That is, when there is a conditional branch in the provisionally determined monitoring range, the whitelist creation unit 104 selects a node at the branch destination that may be executed next and adds it to the provisionally determined monitoring range. This makes it possible to add nodes to the monitoring range of each hook so as not to wastefully monitor memory areas that are not executed on the software. Therefore, it is possible to determine the monitoring range of a hook so as to reduce the number of monitoring times while reducing the size of the whitelist.

[0083] [Embodiment 2] Next, a configuration example of a monitoring range determination device 200 according to a second embodiment will be described with reference to Fig. 11. The second embodiment corresponds to an embodiment that conceptualizes the above-mentioned embodiments as a higher level. 11, a monitoring range determination device 200 according to the second embodiment includes a CFG generation unit 201 and a monitoring range determination unit 202.

[0084] The CFG generating unit 201 generates a CFG based on the binary of the software to be monitored. The CFG generating unit 201 corresponds to the CFG generating unit 103 according to the above-mentioned first embodiment.

[0085] The monitoring range determination unit 202 provisionally determines an embedding location for embedding a hook in the source code of the software to be monitored based on the CFG, and provisionally determines a monitoring range for the hook whose embedding location has been provisionally determined according to a predetermined rule based on the CFG, and sequentially selects the hooks whose embedding locations have been provisionally determined.The monitoring range determination unit 202 then adds a node to the provisionally determined monitoring range of the selected hook based on a preset allowable processing delay, and determines the monitoring range after the node has been added to the provisionally determined monitoring range of the selected hook as the monitoring range of the selected hook.The monitoring range determination unit 202 corresponds to the whitelist creation unit 104 according to the above-mentioned first embodiment.

[0086] According to the second embodiment, nodes can be added to the monitoring range of each hook while taking into consideration the allowable processing delay. Therefore, the monitoring ranges can be consolidated to reduce the size of the whitelist, while preventing the processing delay of the tamper detection process from increasing beyond the allowable processing delay, and the monitoring range of the hook can be determined to be within an appropriate range.

[0087] The monitoring range determination unit 202 may add nodes to the provisionally determined monitoring range of the selected hook so that the size of the monitoring range does not exceed a threshold size according to the allowable processing delay.

[0088] In addition, the monitoring range determination unit 202 may select a node to add to the monitoring range so that the proportion of nodes that may be executed next after the nodes included in the monitoring range is increased in the provisionally determined monitoring range of the selected hook.

[0089] In addition, the monitoring range determination unit 202 may decide to delete a hook that has been provisionally determined to monitor a node that has been added to the provisionally determined monitoring range of the selected hook, from among the hooks whose embedding locations have been provisionally determined.

[0090] The specified rule may also be a rule that traces all descendant nodes of a node containing a target hook whose embedding location has been tentatively determined, through nodes that do not contain hooks, and adds the nodes from the node containing the target hook to the node immediately preceding the node containing the next hook to the monitoring range of the target hook.

[0091] The predetermined rule may be a rule that adds a node including a target hook whose embedding location has been tentatively determined to a monitoring range of the target hook.

[0092] The tampering detection function may be a whitelist-type tampering detection function created as a list of hash values ​​within the monitoring range of the hook.

[0093] [Embodiment 3] Next, an example of a hardware configuration of the monitoring range determining device 300 according to the third embodiment will be described with reference to FIG. 12, a monitoring range determining device 300 according to the third embodiment includes a processor 301 and a memory 302. The processor 301 and the memory 302 are connected to each other.

[0094] The processor 301 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 301 may include multiple processors.

[0095] The memory 302 is configured by a combination of volatile memory and non-volatile memory. The memory 302 may include storage located away from the processor 301. In this case, the processor 301 may access the memory 302 via an I (Input) / O (Output) interface (not shown).

[0096] The monitoring range determination devices 100 and 200 according to the first and second embodiments described above may have the hardware configuration shown in FIG. 12. A program is stored in the memory 302. This program includes a set of instructions (or software code) for causing the computer to perform one or more functions described in the first and second embodiments described above when the program is loaded into the computer. The input / output unit 101, the build unit 102, the CFG generation units 103 and 201, the whitelist creation unit 104, and the monitoring range determination unit 202 in the monitoring range determination devices 100 and 200 described above may be realized by the processor 301 reading and executing the programs stored in the memory 302. The storage unit 105 in the monitoring range determination device 100 described above may be realized by the memory 302.

[0097] The above-mentioned programs may also be stored on non-transitory computer-readable media or tangible storage media. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic or other form of propagated signal.

[0098] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by a person skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure.

[0099] For example, the size of a single node may exceed a threshold size derived from a preset allowable processing delay. In such a case, even if the hook is provisionally placed at the beginning of the node and the monitoring range of the hook is provisionally set to only the node, the processing delay of the tamper detection process will increase beyond the allowable processing delay. Therefore, if the size of a single node is too large and exceeds the threshold size, the node may be divided by the threshold size, and then the hook may be provisionally placed and the monitoring range may be provisionally determined. [Explanation of symbols]

[0100] 100 Monitoring range determination device 101 Input / output section 102 Build Department 103 CFG generation section 104 Whitelist Creation Department 105 Storage section 200 Monitoring range determination device 201 CFG generation section 202 Monitoring range determination unit 300 Monitoring range determination device 301 Processor 302 Memory

Claims

1. A monitoring range determination device that determines a monitoring range of a tamper detection function calling function that is incorporated together with a tamper detection function for software to be monitored, comprising: a CFG generator that generates a control flow graph (CFG) based on the binary of the software; A monitoring range determination unit, The monitoring range determination unit is tentatively determining, based on the CFG, an incorporation location for incorporation of the tamper detection function calling function into a source code of the software, and tentatively determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function calling function whose incorporation location has been tentatively determined; Sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined, adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; determining a monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function as the monitoring range of the selected tamper detection function calling function; Monitoring range determination device.

2. The monitoring range determination unit is adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function so that the size of the monitoring range does not exceed a threshold size according to the allowable processing delay; The monitoring range determining device according to claim 1 .

3. The monitoring range determination unit is selecting a node to be added to the monitoring range so that a ratio of nodes that may be executed next after the nodes included in the monitoring range is increased in the provisionally determined monitoring range of the selected tamper detection function calling function; The monitoring range determination device according to claim 1 or 2.

4. The monitoring range determination unit is determining to delete the tamper detection function calling function that has been provisionally determined to monitor the node added to the provisionally determined monitoring range of the selected tamper detection function calling function from among the tamper detection detection function calling functions whose embedding locations have been provisionally determined; The monitoring range determining device according to any one of claims 1 to 3.

5. the predetermined rule is a rule that, among all descendant nodes of a node including a target tamper detection function calling function whose embedding location has been provisionally determined, traces nodes that do not include the tamper detection function calling function, and adds nodes from the node including the target tamper detection function calling function to a node immediately preceding the next node including the tamper detection function calling function to a monitoring range of the target tamper detection function calling function; The monitoring range determining device according to any one of claims 1 to 4.

6. the predetermined rule is a rule for adding a node including a tamper detection function calling function of the target whose embedding location has been tentatively determined to a monitoring range of the tamper detection function calling function of the target. The monitoring range determining device according to any one of claims 1 to 4.

7. The tampering detection function is a whitelist-type tampering detection function created as a list of hash values ​​of a monitoring range of the tampering detection function calling function. The monitoring range determining device according to any one of claims 1 to 6.

8. A monitoring range determination method executed by a monitoring range determination device that determines a monitoring range of a tamper detection function calling function that is incorporated together with a tamper detection function in software to be monitored, comprising the steps of: generating a control flow graph (CFG) based on the software binary; provisionally determining, based on the CFG, an incorporation location for incorporation of the tamper detection function calling function into the source code of the software, and provisionally determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function calling function, the incorporation location of which has been provisionally determined; a step of sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined; adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; determining a monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function as the monitoring range of the selected tamper detection function calling function; Method for determining monitoring range.

9. A computer that determines the monitoring range of a tamper detection function call function that is incorporated together with the tamper detection function for software to be monitored, generating a control flow graph (CFG) based on the software binary; a step of provisionally determining, based on the CFG, an incorporation location for incorporation of the tamper detection function calling function into a source code of the software, and provisionally determining, based on the CFG and in accordance with a predetermined rule, a monitoring range of the tamper detection function calling function, the incorporation location of which has been provisionally determined; a step of sequentially selecting the tamper detection function calling functions whose embedding locations have been provisionally determined; adding a node to the provisionally determined monitoring range of the selected tamper detection function calling function based on a preset allowable processing delay; determining a monitoring range after the node is added to the provisionally determined monitoring range of the selected tamper detection function calling function as the monitoring range of the selected tamper detection function calling function; A program for executing the above.

Images