Fraud-preventing controller, controller for verification task, fraud prevention method, and fraud prevention method for verification task

Abstract

The present invention prevents, by adopting an aggressive defense method, unauthorized use of a computer against new malware such as viruses, without requiring a very large dictionary. A fraud prevention method according to the present invention: inputs location information of an external device or location information of a verification target task provided within an internal device (A1); generates a verification key on the basis of the input location information; stores the verification key in a storage unit; distributes the verification key to the verification target task (A0); when the verification target task is started, requests the verification target task to return the distributed verification key (A2); and compares the verification key returned from the verification target task with the verification key stored in the storage unit to determine whether the verification target task is normal or not (A4).

Description

Anti-fraud controller, controller for verification task, anti-fraud method, and anti-fraud method for verification task

[0001] The present invention relates to an anti-tamper controller, a verification task controller, an anti-tamper method, and an anti-tamper method for a verification task, for preventing unauthorized use of a computer by a foreign substance such as a virus.

[0002] Conventionally, various security software programs have been proposed to protect computers from various cyber-attacks (see, for example, Patent Document 1). Security software programs are diverse and include defensive defense methods and offensive defense methods.

[0003] Defensive defense security software is software that accurately detects and removes invading foreign substances such as viruses. This software recognizes viruses as "foreign substances" compared to legitimate programs by registering viruses in a dictionary and comparing them with invading foreign substances to determine whether they are viruses or not. Offensive defense security software is a system that eliminates viruses and other foreign substances when they invade the internet or devices.

[0004] Patent No. 5992079

[0005] The above-mentioned defensive security software can only eliminate viruses and other foreign substances that are registered in the dictionary. This requires a huge dictionary and is unable to eliminate new viruses and other foreign substances that are not registered in the dictionary.

[0006] The present invention has been made in consideration of the above circumstances, and aims to provide an anti-fraud controller, a controller for verification tasks, an anti-fraud method, and an anti-fraud method for verification tasks that employ an offensive defense method, which does not require a huge dictionary and can prevent unauthorized use of a computer even against malware such as new viruses.

[0007] In order to achieve the above-mentioned object, the fraud prevention controller of the first invention has a location information input unit that inputs location information of an external device or location information of a task to be verified that is provided in an internal device, a verification key generation unit that generates a verification key based on the location information input to the location information input unit, a memory unit that stores the verification key, a verification key distribution unit that distributes the verification key to the task to be verified, a verification key request unit that requests the task to be verified to return the verification key distributed by the verification key distribution unit when the task to be verified is launched, and a judgment unit that compares the verification key returned from the task to be verified with the verification key stored in the memory unit to judge whether the verification task is normal or not.

[0008] The verification task controller of the second invention includes a location information detection unit that detects location information of an external device or location information of a task to be verified that is provided within an internal device, a location information output unit that outputs the location information detected by the location information detection unit to an anti-tamper controller, a verification key input unit that inputs a verification key distributed by the anti-tamper controller, a memory unit that stores the verification key input by the verification key input unit, a verification key request input unit that inputs a verification key request from the anti-tamper controller, and a requested verification key output unit that outputs the requested verification key from the memory unit.

[0009] A fraud prevention method according to a third aspect of the present invention inputs location information of an external device or location information of a task to be verified that is provided within an internal device, generates a verification key based on the location information, stores the verification key in a memory unit, distributes the verification key to the task to be verified, requests the task to be verified to return the distributed verification key when the task to be verified is started, compares the verification key returned from the task to be verified with the verification key stored in the memory unit, and determines whether the verification task is normal.

[0010] The fraud prevention method for verification tasks according to the fourth invention detects location information of an external device or location information of a task to be verified that is provided within an internal device, outputs the detected location information to an fraud prevention controller, inputs a verification key distributed by the fraud prevention controller, stores the input verification key in a memory unit, inputs a verification key request from the fraud prevention controller, and outputs the requested verification key from the memory unit.

[0011] The fraud prevention program of the fifth invention causes a computer capable of controlling a verification task to input location information of an external device or location information of a task to be verified that is provided in an internal device, generate a verification key based on the location information, store the verification key in a memory unit, distribute the verification key to the task to be verified, request the task to be verified to return the distributed verification key when the task to be verified is started, compare the verification key returned from the task to be verified with the verification key stored in the memory unit, and determine whether the verification task is normal.

[0012] The anti-tampering program for verification tasks of the sixth invention causes a computer capable of controlling the verification task to detect location information of an external device or location information of a task to be verified that is provided within an internal device, output the detected location information to an anti-tampering controller, input a verification key distributed by the anti-tampering controller, store the input verification key in a memory unit, input a verification key request from the anti-tampering controller, and output the requested verification key from the memory unit.

[0013] According to the present invention, it is possible to provide an anti-fraud controller, a controller for verification tasks, an anti-fraud method, and an anti-fraud method for verification tasks that do not require a huge dictionary and can prevent unauthorized use of a computer even against malware such as new viruses.

[0014] 1 is a diagram showing the software hierarchical structure of a von Neumann computer used in each embodiment of the present invention. FIG. 2 is a block diagram showing the configuration of an anti-fraud system according to one embodiment of the present invention. FIG. 3 is a block diagram showing the functions of an anti-fraud controller and a verification task in an anti-fraud system according to one embodiment of the present invention. FIG. 4 is a block diagram showing a computer network including a client PC and a Web computer according to one embodiment of the present invention. FIG. 5 is a block diagram showing the internal configuration of an anti-fraud controller provided in a Web computer according to one embodiment of the present invention. FIG. 6 is a sequence diagram showing verification operations when a Web application is executed according to one embodiment of the present invention. FIG. 7 is a diagram showing verification operations when malware infiltrates a Web application when executing a Web application according to one embodiment of the present invention. FIG. 8 is a flowchart showing operations of a Web tier 1 instance of a Web application according to one embodiment of the present invention. FIG. 9 is a flowchart showing operations of a Web tier 1 instance of a Web application according to one embodiment of the present invention. FIG. 10 is a flowchart showing operations of an anti-fraud controller according to one embodiment of the present invention. FIG. 11 is a flowchart showing operations of an anti-fraud controller according to one embodiment of the present invention. FIG. 12 is a flowchart showing operations of a tier 2 instance according to one embodiment of the present invention. FIG. 13 is a sequence diagram showing operations of checking the validity of an instance performed by the anti-fraud controller according to one embodiment of the present invention. FIG. 14 is a sequence diagram showing operations of preventing fraudulent instances in a user application installed in a computer performed by the anti-fraud controller according to one embodiment of the present invention. FIG. 15 is a flowchart showing operations of an application tier 1 instance of a user application according to one embodiment of the present invention. 1 is a sequence diagram illustrating an operation of preventing unauthorized instances in a management application installed in a computer, the operation being performed by an anti-fraud controller according to an embodiment of the present invention, and a sequence diagram illustrating processing performed by an anti-fraud controller according to an embodiment of the present invention when an OS in a computer is started.1 is a sequence diagram illustrating the processing performed by a fraud prevention controller according to one embodiment of the present invention when an application is launched by an OS in a computer. FIG. 1 is a block diagram illustrating the operation when an initial file is written between a mother host and a target PC in one embodiment of the present invention. FIG. 2 is a block diagram illustrating the operation when an update file is written between a mother host and a target PC in one embodiment of the present invention. FIG. 3 is a flowchart illustrating the operation of a hierarchical key issuance request performed by a fraud prevention controller according to one embodiment of the present invention. FIG. 4 is a flowchart illustrating the operation of a hierarchical key issuance performed by a fraud prevention controller according to one embodiment of the present invention. FIG. 5 is a flowchart illustrating the operation of a hierarchical key confirmation performed by a fraud prevention controller according to one embodiment of the present invention. FIG. 6 is a diagram illustrating how multiple personal information keys are accessed from a mobile terminal to the system in one embodiment of the present invention. FIG. 7 is a sequence diagram illustrating the processing performed by a fraud prevention controller according to one embodiment of the present invention when each hierarchical level in the system is launched. FIG. 8 is a diagram illustrating the personal information key acquired for the first time in one embodiment of the present invention. FIG. 9 is a diagram illustrating the personal information key acquired for the first time and the personal information key acquired for the second time in one embodiment of the present invention.

[0015] An embodiment to which the present invention is applied will now be described with reference to the drawings. Fig. 1 is a diagram showing the hierarchical structure of a von Neumann computer 10 used in an embodiment of the present invention and the arrangement of an anti-tamper controller 16. This von Neumann computer 10 has five layers: a web application layer 11, an application layer 12, a framework layer 13, an OS layer 14, and a firmware layer 15. Note that, although the present embodiment shows a case in which the number of layers is five, the present invention is not limited to this.

[0016] The firmware layer 15 stores the machine language set written on the hardware, an IPL loader (Initial Program Loader), and software that controls the CPU and microcomputer. The OS layer 14 is the area where the OS (operating system) runs to achieve multitasking. The framework layer 13 is an application area called a framework (located within the application layer and often running as a higher-level program) that standardizes the operation of applications, although this varies depending on the application or web application being run.

[0017] The application layer 12 is the area where various applications run. The web application layer 11 is the area where software such as Apache (registered trademark) that operates on a port-by-port basis in conjunction with lines as web applications runs. Applications in this application layer 12 may also perform instruction analysis during execution, such as interpreter-type applications. Figure 1 shows the hierarchical structure when running on a von Neumann computer, and programs at each layer run according to the rule that lower-level programs cannot rewrite the operations of higher-level programs.

[0018] An anti-fraud controller 11a is provided in the web application layer 11, an anti-fraud controller 12a is provided in the application layer 12, an anti-fraud controller 13a is provided in the framework layer 13, an anti-fraud controller 14a is provided in the application layer 14, an anti-fraud controller 14a is provided in the OS layer 14, and an anti-fraud controller 15a is provided in the firmware layer 15. These anti-fraud controllers 11a to 15a are collectively referred to as anti-fraud controller 16.

[0019] 1, fraud prevention controllers 11a to 15a are placed in each of the layers 11 to 15, but it is also possible to provide the fraud prevention controller 11a only in the layer where it is desired to prevent the intrusion of malware such as viruses, for example, in the web application layer 11, and not to place fraud prevention controllers in the other layers 12 to 15. Of course, fraud prevention controllers may be placed in multiple layers, but not in the other layers.

[0020] When malware such as a virus, which is malicious software created with the intention of committing fraud, invades any layer of a computer, the fraud prevention controller 16 (11a to 15a) detects this intrusion and prohibits the operation of programs in that layer. The fraud prevention controller 16 is configured using software (programs) or hardware. Known examples of malware include viruses, worms, spyware, adware, bots, backdoors, and ransomware.

[0021] Next, the operation of the anti-tamper controller 16 will be briefly described. The anti-tamper controller 16 is configured as software or hardware, but in this embodiment it is a program (instance, task) that performs the following operations, and runs as a resident program either on-chip or on the OS as an application. This anti-tamper controller has the following functions: 1) Exclusion of fraudulent locations 2) Conditions related to locations 3) Conditions for checking verification keys (hierarchical keys) 4) Conditions for deleting verification keys (hierarchical keys) Each function will be described below.

[0022] 1) Regarding the Exclusion of Invalid Locations: The fraud prevention controller checks the location information of programs (instances, tasks) such as web applications and user applications. If the location information is not correct, the fraud prevention controller determines that the location is invalid if the location information is a non-local location, as described below. If the program has an invalid location, the fraud prevention controller excludes the program as a program invaded by malware such as a virus (see, for example, the determination unit 108 in FIG. 2B , times A1 and A4 in FIG. 4A , S29 in FIG. 6A , and S103 in FIG. 16A , described below). Furthermore, if malware such as a virus invades a program and the program is rewritten, the location information may be rewritten with invalid information or may be lost.

[0023] In this embodiment, information indicating a location is referred to as location information, and the fraud prevention controller determines whether the location is a local location or a non-local location (a non-local location). Generally, computers and other devices are often connected to form a complete system. In this case, the entire system, including the PC, server (local element device), client PC, CPU, GPU (Graphics Processing Unit), device, and control device (local element device control portion), as well as the software running on the local element device (local element software), and the location where the software runs, are referred to as the "local location." On the other hand, elements that do not belong to the local location and have no relationship to the system are referred to as "non-local (external) locations, non-local element devices, and non-local element device control portions." In other words, the scope of the local location and non-local location changes depending on changes in the system situation.

[0024] For example, if the anti-tamper controller is provided in the application layer (see, for example, FIG. 9), it acquires location information of the location where the application program is stored, and if this location information is a local location, it determines that the location is an unauthorized location (i.e., a normal location) (see, for example, C1, C3, C4, etc. in FIG. 9 described later). Alternatively, it may check the location information of the source of the application software launch, and check whether this location information is recorded in the unauthorized location DB 71 to determine whether the location is an unauthorized location (see, for example, C1, C3, C4, etc. in FIG. 9 described later).

[0025] Furthermore, if the fraud prevention controller is provided in the web application, the fraud prevention controller may determine whether the location information of the access source is a local location, and if it is a non-local location, may determine that the location is an unauthorized location. Furthermore, the fraud prevention controller may search whether the location information of the access source (such as IP address information or fingerprint information) is recorded in the unauthorized location DB 71 (see FIG. 16A ) (see, for example, times A1 and A3 in FIG. 4A , S29 in FIG. 6A , and S101 in FIG. 16A , which will be described later). If the location information is recorded in the unauthorized location DB 71, the fraud prevention controller determines that the location is an unauthorized location, and prohibits the launch of the web application at that point (see, for example, S33 in FIG. 6A , S103 and S107 in FIG. 16A , which will be described later).

[0026] When a computer including a fraud prevention controller is connected to an external network, the determination of whether the location information is valid may be based on whether the external location information is a local location or a non-local location. Even if connected to an external network, if a computer or other device is connected to multiple devices and forms a complete system, the location information of devices (including computers, etc.) within this system can be considered a local location. Furthermore, when a request is made from an OS or application within a PC to confirm whether a location is fraudulent, if the location information is within the computer system, it has unique alphanumeric characters as a local location, so whether the location information is fraudulent can be determined by determining whether the location information is internal local location information. In other words, if the location information is external, it is determined to be fraudulent. Furthermore, when determining whether the location information is valid, an external fraud location DB may be used. On the other hand, if the computer is not connected to an external network, a fraud location DB may be provided within the computer and fraud location information may be stored internally.

[0027] Specifically, the location information may be, for example, address information of the source of an external device or address information of the launch source of a program installed in an internal computer system, which instructs the verification task to operate. Furthermore, the location information may be, for example, an address such as a MAC address or an IP address, which is expressed by alphanumeric characters and is used. Since MAC addresses and IP addresses may be spoofed when accessed from outside, location information that can prevent such spoofing may be used. Furthermore, the information is not limited to address information, and may also be individual PC information such as a fingerprint, as described below. Note that, for convenience of explanation, the term "PC" is used in this specification; however, in connection with the aforementioned "local," this also includes element devices (PC, server, client PC, control device, etc.) included in the local location.

[0028] 2) When a request for issuing a hierarchical key for a location-related condition is received (for example, at time A5 in FIG. 4A, see FIG. 16A), the fraud prevention controller issues hierarchical keys for the number of layers based on the location information. In this case, the location information refers to the following information:

[0029] a) In the case of web applications, location information includes individual PC information such as fingerprint and client-side IP address information. However, this information is not limited to these, and any information that can determine whether the location of the sender or launcher is a local location or a non-local location, as will be described later, will suffice. b) In the case of PC internal applications, the application here is a program that runs inside the PC, and its running location is on the CPU within the computer. In other words, it is fixed to the location closest to the CPU (the local location mentioned above), and this is used as location information. c) In the case of an OS As with PC internal applications, the location where the OS runs is on the CPU within the computer. In other words, it is fixed to the location closest to the CPU (the local location mentioned above), and this is used as location information.

[0030] 3) Hierarchical Key Verification Conditions The fraud prevention controller checks the following items for the hierarchical keys received from each instance: a) Hierarchical Key Existence Check: Checks whether the received hierarchical key exists in the stored hierarchical keys, and also checks whether the corresponding location is invalid, i.e., whether it is a non-local location. b) Hierarchical Key Interaction Check: Determines whether the upper hierarchical key (if the hierarchical level is 2, the one at hierarchical level 1) and the lower hierarchical key belong to the same instance (for example, see S127 and S129 in FIG. 17, described later).

[0031] 4) Conditions for Deleting Hierarchical Keys: When all hierarchical instances related to the same location instance have ended, the hierarchical keys recorded in the operating location DB 75 are deleted for the active hierarchical keys (see, for example, times T12 and T13 in FIG. 4A, and times C9 and C13 in S9 in FIG. 6C). When the hierarchical key recorded in the operating location DB 75 is deleted, the active hierarchical key of the two hierarchical keys no longer exists, and they will not be determined to be identical as a result of comparison. This prevents unauthorized use of hierarchical keys.

[0032] Next, using FIG. 2A , the fraud prevention function of the fraud prevention controller 16 (11a-15a), particularly the fraud prevention function based on the identity of two verification keys, will be described. The hierarchical key is a verification key created for each hierarchical level. Here, the task to be verified is software such as a program, instance, or task, which performs processing in response to instructions from the sender or is activated in response to instructions from the invocation source. The fraud prevention controller is software that, in response to a fraud verification request, checks the creator (original sender) and the hierarchical level to be executed, and verifies the fraud of the corresponding program, instance, or task. In this embodiment, the fraud prevention controller is described as being implemented by software, but it may also be configured by hardware. The fraud prevention controller can prevent malware such as viruses from invading software such as programs, instances, and tasks.

[0033] The fraud prevention controller 16 is located one layer above the verification target task (instance, program) 18. This is to prevent tampering from the verification target task (lower task). However, as an exception, if the verification target task is in firmware, the fraud prevention controller 16 is located at the same layer. The fraud prevention controller 16 generates the first verification key 17a through the nth verification key 17n. These verification keys may be prepared in advance, or the fraud prevention controller 16 may generate them based on location information, random numbers, or the like. The number of digits and the type of characters used in the verification key may also be set appropriately. Numbers or symbols indicating that the verification key is a verification key may also be set in the verification key, and a header or the like indicating that it is a verification key may also be added. Note that in FIG. 2A, there is no distinction between layers, so the term "verification key" is used, but if verification keys are created for each layer, they may also be called "hierarchical keys."

[0034] The verification target task 18 is the target for determining whether malware such as a virus has invaded, and in FIG. 1 , it corresponds to the programs (instances, tasks, OS) or hardware in the web application layer 11 to firmware layer 15. The fraud prevention controller 16 (11a to 15a) distributes the first to nth verification keys 17a to 17n to the verification target task 18 at time T=Ta. The verification target task 18 writes the distributed verification keys 17a to 17n into the program (instance, task) and stores the modified program in memory. In other words, the verification keys are written and stored in the program.

[0035] At time T=Tb, the verification task 18 is activated, and this is communicated to the fraud prevention controller. In response to this communication, the fraud prevention controller requests the verification target task 18 to return the "nth to x-1th verification key." Since the verification task 18 stores the first to nth verification keys 17a to 17n, at time T=Tc, it searches for the nth to x-1th verification key from its stored values ​​and transmits the value of this verification key to the fraud prevention controller 16.

[0036] If malware such as a virus invades the verification target task 18, the program (instance, task) of the verification target task 18 is rewritten, and in the process, the verification keys 17a to 17n are also rewritten or erased. In other words, if malware has invaded the verification target task 18, at least a portion (including the verification key) of the program (instance, task) of the verification target task 18 is rewritten, and the verification target task 18 is unable to return the correct "verification key number (x-1) from n" to the fraud prevention controller 16. On the other hand, if malware has not invaded the verification target task 18, the verification target task 18 can return the correct "verification key number (x-1) from n" to the fraud prevention controller 16. Therefore, the fraud prevention controller 16 can determine whether malware has invaded the verification target task 18 by determining whether the verification key returned from the verification target task 18 is the same as the verification key distributed in advance.

[0037] If the fraud prevention controller 16 determines that malware such as a virus has invaded, it deletes the verification key and prohibits execution of the program (instance, task) of the verification target task 18. Furthermore, if verification keys have been distributed to verification tasks higher than the verification target task 18, these verification keys may also be deleted.

[0038] The verification keys 17a to 17n distributed by the fraud prevention controller 16 to the verification task 18 at time T=Ta may be generated based on location information and / or random numbers. In this case, the verification keys may be generated using AI. The location information may be, for example, the MAC address or fingerprint of a PC or the like, or in the case of a router, the IP address of the router.

[0039] Furthermore, the verification key may be retained after generation, or may be changed based on a random number or AI. The verification key may be changed at regular intervals or irregularly. The fraud prevention controller 16 may change the verification key and distribute the changed verification key to the task to be verified. Alternatively, the fraud prevention controller 16 and the verification task 18 may synchronize and change the verification key simultaneously. To prevent tampering, the fraud prevention controller 16 may change the extent to which it checks the verification key generation history. In this case, even if a fraudster is able to obtain some of the verification keys, the probability of preventing impersonation can be increased.

[0040] The verification keys 17a to 17n may be generated in hardware within a network environment. In this case, the generation of the verification keys is not controlled externally. Furthermore, as described above, the verification keys may be changed as needed using random numbers or AI. This significantly reduces the probability that an identical verification key will exist, even if someone attempts to obtain and use a verification key generated by other hardware.

[0041] Furthermore, if logic is executed to return the verification key to the tamper prevention controller 16 at the time when the verification target task 18 is started (T=Tb), task inspection is performed before any substantial operation within the task occurs. Therefore, task execution is blocked before any actual damage caused by malware such as a virus occurs, thereby reducing the possibility of actual damage occurring.

[0042] Furthermore, the fraud prevention controller 16 verifies the presence of malware such as a virus when a task is executed, and prohibits the execution of the verification target task 18 if malware is present. In other words, the system does not delete the file that loaded the erroneous task. Therefore, to eliminate malware such as a virus, a virus removal application can be used.

[0043] Furthermore, as described above, if the tamper prevention controller 16 is configured to change the verification key at a unique timing or interval, the probability of obtaining a unique verification key is high, and resistance to tampering is high. It is also possible to create a security environment for each layer of the von Neumann computer shown in FIG. 1. This allows for a multi-layered security structure, making it possible to increase security strength. Furthermore, because the tamper prevention controller 16 according to this embodiment does not have a virus dictionary, the size of the security software itself can be reduced, and therefore it can be easily installed in hardware security systems for microcomputers and other devices, not just PCs.

[0044] Furthermore, since the anti-tamper controller 16 does not need to have a dictionary for viruses and other malware, there is no need to update the dictionary in response to changes in viruses. Therefore, it is highly resistant to changes in viruses and other malware. The anti-tamper controller 16 may also record the update history of the verification key, the interval between changes, and the worst-case virus damage, and the virus response center may obtain the records to change the interval between verification key generation, the type of random number, and so on.

[0045] Next, the anti-fraud controller and the verification task controller will be described using the functional block diagram shown in FIG. 2B. The anti-fraud controller 100 corresponds to the anti-fraud controller 16 in FIG. 2A, and the verification target task (including the verification task controller) 200 is provided within the verification target task 18 in FIG. 2A and has the function of controlling the verification target task 18. The anti-fraud controller 100 determines whether the verification target task (program, instance) (specifically, the verification target program 204a within the verification target task 200) is infected with malware such as a virus, and if infected, prohibits the execution of the verification target task. Therefore, the verification target task is prohibited from starting its operation until the determination by the anti-fraud controller 100 is completed.

[0046] The fraud prevention controller 100 includes a processor configured with an ASIC (Application Specific Integrated Circuit) including a CPU (Central Processing Unit) and various peripheral circuits. The fraud prevention controller 100 includes a location information input unit 101, a verification key generation unit 102, a memory unit 103, a verification key distribution unit 104, a startup information input unit 105, a verification key request unit 106, a verification key input unit 107, and a determination unit 108. The memory unit 103 is an electrically rewritable nonvolatile memory capable of storing programs and the like. Each unit other than the memory unit 103 is mainly realized according to the CPU and programs stored in the nonvolatile memory. However, some of these functions may be realized by hardware.

[0047] The verification target task 200 has a processor configured with an ASIC (Application Specific Integrated Circuit) including a CPU (Central Processing Unit) and various peripheral circuits. The verification task 200 has a location information detection unit 201, a location information output unit 202, a verification key input unit 203, a memory unit 204, a verification target program 204a, a startup information output unit 205, a verification key request input unit 206, a requested verification key output unit 207, a judgment result input unit 208, and a verification task execution / prohibition unit 209. The memory unit 204 is an electrically rewritable nonvolatile memory capable of storing programs and the like. Each unit other than the memory unit 204 is mainly realized in accordance with the CPU and programs stored in the nonvolatile memory. However, some of these functions may be realized by hardware.

[0048] The verification target program 204a is a program (instance, task) that is the target of the fraud prevention controller 100's determination of whether malware such as a virus has infiltrated, and various programs such as web programs and user application programs are applicable. Programs that realize the functions of each unit, such as the location information detection unit 201 and the location information output unit 202, are stored in the storage unit 204, are added on to the verification target program 204a, and are executed when determining whether the verification target program 204a is infected with malware such as a virus. Note that the programs that realize the functions of each unit may be separate programs from the verification target program 204a.

[0049] Each part of the fraud prevention controller 100 and the verification task 200 is implemented primarily by a CPU and software (programs, instances, tasks) stored in non-volatile memory. However, some of these functions may also be implemented by hardware. The verification task controller in the verification target task 200 is provided as an attachment to the program for executing the verification target task 18. Therefore, when the verification task controller is implemented by software, a controller such as a CPU for executing the verification target task may also serve as the verification task controller, or a controller dedicated to executing the verification task controller may be provided.

[0050] The task to be verified is at least one of a web program, an application program, a management application, and an OS, and is software such as a program, an application, an instance, or a task. The task to be verified may have multiple hierarchies. For example, the example shown in FIG. 4A (described later) has three hierarchies: a web hierarchical level, a hierarchical level 2, and a hierarchical level 3. The examples shown in FIGS. 8, 9, 11, 12, 13, and 19 also have multiple hierarchies.

[0051] The components of the fraud prevention controller 100 and the verification target task 200 will be described. The location information detection unit 201 detects location information of the verification target task provided in an external device or an internal device (e.g., time A1 in FIG. 4A , S3, S5 in FIG. 5A , etc.). The location information is information indicating the location where the verification target program 204 a is stored, and as described above, is information indicating the address that instructed the verification target task to run, such as the address information of the sender or the address information of the program launcher. For example, if the verification target task is a Web application, the location information is the sender (launcher) address (e.g., MAC address, IP address, etc.) of a client PC, router, etc. If the verification target task is an application provided inside a computer such as a personal computer (PC) or server, the location information is the address of the computer that launched the application. Immediately after the verification target program is installed in the storage unit 204, the location information is the location where the verification target program is stored. The location information detection unit 201 functions as a location information detection unit that detects location information of an external device or location information of a task to be verified that is provided in an internal device.

[0052] When the location information detection unit 201 detects location information, the location information output unit 202 outputs the location information to the location information input unit 101 in the fraud prevention controller 100 (see, for example, time A1 in FIG. 4a and S23 in FIG. 6A, which will be described later). The location information output unit 202 functions as a location information output unit that outputs the location information detected by the location information detection unit to the fraud prevention controller. The location information input unit 101 functions as a location information input unit that inputs location information of an external device or location information of a verification target task provided in an internal device.

[0053] The location information input unit 101 outputs the input location information to the verification key generation unit 102. The verification key generation unit 102 generates a verification key based on the location information (see, for example, time A0 in FIG. 4A , time A0-1 in FIG. 4B , and S21 in FIG. 6A ). For example, a random number may be generated by applying a hash function to a timestamp of the location information, and this value may be used as the location information. The verification key generation unit 102 functions as a verification key generation unit that generates a verification key based on the location information input to the location information input unit. The verification key generation unit may generate multiple verification keys (see, for example, time A0 in FIG. 2A and FIG. 4A , and S21 in FIG. 6A , which will be described later). If there are multiple hierarchies, the verification key generation unit may generate a verification key for each of the multiple hierarchies (see, for example, time A0 in FIG. 4A and S21 in FIG. 6A , which will be described later).

[0054] Note that generating a verification key based on location information makes it difficult for an intruder into the task to be verified to generate a verification key identical to the verification key generated by the verification key generation unit. If such security of the verification key is not required, the verification key generation unit does not need to generate the verification key based on location information. In this case, the verification key generation unit may simply generate the verification key using, for example, random numbers.

[0055] The storage unit 103 stores the verification key generated by the verification key generation unit 102 in memory (see, for example, memory 50B in FIG. 3B). Furthermore, if the functions of each unit in the fraud prevention controller 100 are realized by a program (instance, task), this program is also stored in the storage unit 103. However, unlike the verification target task 200, the verification key is not written into the program, but is stored separately in the storage unit 103 or another memory. Therefore, even if malware such as a virus invades the fraud prevention controller, the verification key in the fraud prevention controller 100 will not be rewritten. The storage unit 103 may also store location information.

[0056] The storage unit 103 functions as a storage unit that stores a verification key. The verification key distribution unit 104 (see, for example, time A0 in FIG. 4A and S21 in FIG. 6A , which will be described later) transmits the verification key generated by the verification key generation unit 102 to the verification key input unit 203 in the task 200 to be verified. The verification key distribution unit 104 functions as a verification key distribution unit that distributes a verification key to the task to be verified. The verification key distribution unit may distribute multiple verification keys to the task to be verified (see, for example, time A0 in FIG. 4A and S21 in FIG. 6A , which will be described later).

[0057] The verification key input unit 203 stores the verification key sent from the fraud prevention controller 100 in the storage unit 204 (see, for example, memory 45B in FIG. 3B and S1 in FIG. 5A). The verification key input unit 203 functions as a verification key input unit that inputs the verification key distributed by the fraud prevention controller. Furthermore, if there are multiple verification keys, the verification key input unit inputs the multiple verification keys and stores these multiple verification keys in the storage unit. If there are verification keys for multiple layers, the verification key input unit inputs a verification key for each of the multiple layers.

[0058] The storage unit 204 functions as a storage unit that stores the verification key input by the verification key input unit. The storage unit stores the verification key by writing the verification key into the task to be verified (for example, see time A0 in FIG. 4A, time A1-1 and A1-2 in FIG. 4B, S1 in FIG. 5A, etc.). Note that if the storage area for the verification key is set to an area that will be rewritten when malware such as a virus invades and rewrites all or part of the task to be verified, the intrusion of malware such as a virus can be easily detected.

[0059] The startup information output unit 205 notifies the startup information input unit 105 of the fraud prevention controller 202 of information indicating the sender or starter of the task to be verified. For example, if the task to be verified is a Web application, when the Web application is accessed from an external client PC and the Web application is started, or when an application within the computer is started, the startup information output unit 205 notifies the startup information input unit 105 of the fraud prevention controller 100 that the task to be verified has started (see, for example, time A1 in FIG. 4B , S23 in FIG. 6A , time C1 in FIG. 9 , S3A in FIG. 10 , etc.). Note that if the location information detection unit 201 can detect the start-up together with the detection of location information, the startup information output unit 205 may be omitted.

[0060] When the activation information input unit 105 receives the activation information, it outputs the activation information to the verification key request unit 106. Upon receiving the activation information, the verification key request unit 106 requests the verification key request input unit 206 of the task 200 to return a verification key via the verification key request unit 106 (see, for example, time A2 in FIG. 4A and S25 in FIG. 6A ). The verification key request unit 106 functions as a verification key request unit that requests the task 200 to return a verification key distributed by the verification key distribution unit when the task 200 is started. Furthermore, the verification key request unit requests the return of a verification key stored in the storage unit during execution of the task 200. If multiple verification keys are distributed, the verification key request unit may specify one of the multiple verification keys and request the task 200 to return it.

[0061] When a verification key is requested to be returned, the verification key request input unit 206 searches for a verification key stored in the memory unit 204 and transmits it to the verification key input unit 107 of the fraud prevention controller 100 via the requested verification key output unit 207 (see, for example, time A2 in FIG. 4A and S25 in FIG. 6A ). The verification key request input unit 206 functions as a verification key request input unit that inputs a verification key request from the fraud prevention controller. The requested verification key output unit 207 functions as a requested verification key output unit that outputs the requested verification key from the memory unit. If there are multiple verification keys, the verification key request input unit searches for a specified verification key among the multiple verification keys and returns it to the fraud prevention controller via the requested verification key output unit. If there are verification keys for each layer, the verification key request input unit searches for the verification key of the specified layer and returns it to the fraud prevention controller via the requested verification key output unit. The verification key input unit 107 sends the input verification key to the determination unit 108.

[0062] Based on the location information sent from the location information input unit 101, the determination unit 108 determines whether the location information detected in the verification target task is a local location, a non-local location (i.e., illegal), or normal. As described above, when multiple computer devices are connected to form a complete system, the entire system, including the computer and other components that make up the system, the software running on the local component devices, and the location where the software runs, are considered to be "local locations." Therefore, the determination unit 108 determines whether the verification target task is illegal by determining whether the location information of the source (location information of the verification target task itself) or the launcher of the verification target task is a local location. Alternatively, illegal locations may be stored in memory in advance, and the determination may be made based on whether the location information sent from the verification task controller matches the illegal location stored in memory. The determination unit 108 functions as a determination unit that determines whether the location information input to the location information input unit is illegal.

[0063] The determination unit 108 also compares the verification key stored in the storage unit 103 in the fraud prevention controller 100 with the verification key stored in the storage unit 204 in the task 200 to be verified. The verification key stored in the storage unit 204 in the task 200 to be verified was generated by the verification key generation unit 102 and should therefore match the verification key stored in the storage unit 103. If the task to be verified is infected with malware such as a virus, the verification key stored in the storage unit 204 will be rewritten or erased. As a result, the two verification keys will not match. By comparing the two, it is possible to determine whether the task to be verified is infected with malware such as a virus. In this way, the determination unit 108 uses the location information and the verification key to determine whether the task to be verified is infected with malware such as a virus.

[0064] The determination unit 108 functions as a determination unit that compares the verification key returned from the task to be verified with the verification key stored in the storage unit to determine whether the task to be verified is valid. The determination unit determines that the location information of the sender or launcher of the task to be verified, input into the location information input unit, is invalid if it is a non-local location. As described above, in this embodiment, the entire system consisting of the PC, server (local element device), client PC, CPU, GPU, device, control device (local element device control part), software running on the local element device (local element software), and the location where the software runs is referred to as the "local location." On the other hand, elements that do not belong to the local location and have no relationship to the system are referred to as "non-local (external) locations, non-local element devices, and non-local element device control parts." Therefore, the determination unit detects whether the input location information is a local location or a non-local location, and determines whether the location information is invalid based on the detection result (see, for example, time A3 in FIG. 4A and S29 in FIG. 6A).

[0065] The determination unit compares the verification key returned from the task to be verified with the verification key stored in the storage unit to determine whether the task to be verified is normal. If there are multiple hierarchies, the determination unit may use a verification key for each hierarchical level to determine whether each hierarchical level of the task to be verified is normal (see, for example, S127 and S129 in FIG. 17 , which will be described later).

[0066] The judgment result of the judgment unit 108 is sent to a judgment result input unit 208 in the task to be verified 200, and the judgment result is notified to a verification task execution / prohibition unit 209. If the task to be verified is invalid, that is, if it is infected with malware such as a virus, execution of the task to be verified is prohibited. On the other hand, if the task to be verified is not infected with malware such as a virus, execution of the task to be verified is permitted. In this embodiment, if the task to be verified 200 does not have a virus removal program for eliminating (removing) malware such as a virus, it can be removed using a commercially available virus removal program or the like.

[0067] 2B illustrates input units (input ports) and output units (output ports) such as the location information output unit 202 and the verification key input unit 203 separately, but the input / output units may be combined into one. For example, in the fraud prevention controller 100, the location information input unit 101, the startup information input unit 105, and the verification key input unit 107 may be collectively referred to as the "input unit," and the verification key distribution unit 104 and the verification key request unit 106 may be collectively referred to as the "output unit." In addition, in the verification target task 200, the verification key input unit 203, the verification key request input unit 206, and the judgment result input unit 208 may be collectively referred to as the "input unit," and the location information output unit 202, the startup information output unit 205, and the requested verification key output unit 207 may be collectively referred to as the "output unit." In addition, the fraud prevention controller 100 and the verification target task 200 have been described as being realized by different CPUs and software (programs, instances, and tasks) stored in non-volatile memories, respectively. Separate configurations can increase the reliability of preventing the intrusion of malware such as viruses. However, if a slight decrease in reliability is acceptable, the functions of the verification target task and the tamper prevention controller may be realized by a program that integrates the same CPU and two pieces of software, or by the same CPU and two different pieces of software.

[0068] Next, the operation of the anti-tamper controller 49 in the Web computer 40 will be described with reference to Figures 3A to 7. In this example, the verification task controller 200 shown in Figure 2B is provided in processor 45A arranged in the Web tier 45, and the anti-tamper controller 100 is provided in processor 50A in the anti-tamper controller 50. In this embodiment, both controllers are realized by software stored in memories 45B and 50B.

[0069] 3A shows a computer network including a client PC (personal computer) 20, a Web computer 40, and the like. The client PC 20 is a typical general-purpose personal computer used by a user. The client PC 20 has a processor 21, memory 22, an input / output interface 23, and a communication interface 26. A display device 24 and an input device 25 are connected to the input / output interface 23.

[0070] The processor 21 includes a CPU (Central Processing Unit) and is configured as an ASIC (Application Specific Integrated Circuit) including various peripheral circuits. The memory 22 includes an electrically rewritable nonvolatile memory and stores programs for operating the processor 21 and various other data.

[0071] The input / output interface 23 allows a user of the client PC 20 to input information to the computer using an input device 25 such as a keyboard, and also outputs information from the computer to a display device 24 or a speaker. The communication interface 26 is an interface for communicating with the outside of the client PC 20.

[0072] The communication interface 26 is an interface for communicating with the outside of the client PC 20, and in this embodiment, is connected to a router 31. The router 31 has the function of assigning global IP addresses to multiple terminal devices and connecting the multiple terminal devices to an Internet line. The client PC 20 is connected to a communication network such as the Internet via the router 31, and is connected to an Internet provider 32. The client PC 20 then connects via the provider 32 to a router 33 of a Web computer 40 that corresponds to a URL specified by the client PC 20.

[0073] The web computer 40 is a computer that functions as a web server. The web computer 40 has a processor 41, memory 42, database 43, and communication interface 44. The processor 41 includes a CPU (Central Processing Unit) and is configured as an ASIC (Application Specific Integrated Circuit) that includes various peripheral circuits. The memory 42 includes an electrically rewritable nonvolatile memory and stores programs for operating the processor 41 and various other data. The database 43, as a web server, stores data for displaying information based on requests from the client PC 20.

[0074] The communication interface 44 is connected to the router 33 and is connected to an Internet line via the router 33. The communication interface 44 has multiple layers, namely, a web application layer 45, an application layer 46, a framework layer 47, an OS layer 48, and a firmware layer 49, similar to the von Neumann computer 10 shown in FIG.

[0075] In addition, an anti-fraud controller 50 is provided in the web application layer 45. In the example shown in FIG. 1, the anti-fraud controller 16 is provided in each layer. However, in the example shown in FIG. 3A, the anti-fraud controller may be provided in another layer, not just the web application layer 45. The anti-fraud controller 50 has the same functions as the anti-fraud controller 16 shown in FIG. 2A. That is, the anti-fraud controller 50 distributes a verification key in advance to a task to be verified (e.g., a program located in the web application layer 45), and when the task to be verified is accessed from the client PC 20 and executed, the anti-fraud controller requests transmission of the verification key to determine whether or not fraud has occurred. Note that the anti-fraud controller is not limited to being provided in a communication interface, but may also be provided in another processor, such as the processor 41.

[0076] 3B is a block diagram showing the configuration of the web layer 45 and fraud prevention controller 50 provided within the communication interface 44. The web layer program is placed within the web layer 45, and this web program is stored in memory 45B and executed by the processor 45A. In addition to the processor and memory, it also has an ASIC that constitutes peripheral circuits such as the processor. The web program is divided into multiple layers, layer 1, layer 2, and layer 3. After layer 1 is started, it branches to layer 2 as needed, and the program can then proceed to layer 3 and lower layers.

[0077] 3B, the fraud prevention controller 50 is placed in the Web layer, but it is preferable to place it in a layer higher than Layer 1 of the Web layer to prevent tampering. The fraud prevention controller 50 may be configured with an ASIC or the like that constitutes a peripheral circuit in addition to the processor 50A and memory 50B, and may also share the processor 45A and memory 45B in the Web layer. In this embodiment, the fraud prevention program is stored in memory 50B, and the fraud prevention function is realized by being executed by the processor 50A.

[0078] Next, a verification operation for preventing fraud when a Web application (program) stored in a computer (including a server) is executed will be described with reference to the sequence diagrams shown in FIGS. 4A and 4B.

[0079] In the case of a web application installed in a computer, it may be accessed by an external client PC, and the location at the time of launch of the web application (instance) may hold the location information (identification information and IP address) of the external computer. This location information is determined to be local location information, and if it is non-local location information, it is determined to be a fraudulent instance. Generally, a client PC accessing a web application is often determined to be in a local location when viewed from the perspective of the entire system. The fraud prevention controller may also determine whether it is a fraudulent instance by comparing it with fraudulent locations recorded in a database (DB).

[0080] In addition, the verification key described with reference to FIG. 2A is written and stored in the programs (instances, tasks) of each hierarchical layer of the web application, and by detecting this hierarchical key, it is possible to determine whether an instance is fraudulent. That is, the fraud prevention controller creates a hierarchical key and distributes it to a layer of the web hierarchical layer (layer 1 in this embodiment). When a client PC accesses the web hierarchical layer, the fraud prevention controller requests the web hierarchical layer to transmit the hierarchical key and compares the previously distributed hierarchical key with the hierarchical key transmitted from the web hierarchical layer to determine whether the instance is fraudulent. If malware such as a virus is introduced from an external client PC, the web application in the web hierarchical layer is rewritten, and the hierarchical key is also rewritten. Therefore, by comparing the two hierarchical keys, it is possible to determine whether the instance is fraudulent or legitimate.

[0081] The client PC shown in the top row of Fig. 4A corresponds to client PC 20 in Fig. 3, the router corresponds to router 31 in Fig. 3, and the provider corresponds to provider 32 in Fig. 3. Furthermore, tiers 1 to 3 of the web hierarchy correspond to web application layer 45 in Fig. 3, and the fraud prevention controller corresponds to web prevention controller 50 in Fig. 3. Within web application layer 45, the program starts at tier 1 and progresses downward through tiers 1 to 3 as it branches.

[0082] At time A0, when a web application (program) is installed in the web application layer 45, the fraud prevention controller 50 generates a layer 1 key, a layer 2 key, and a layer 3 key for each layer and stores these layer keys in the memory of the fraud prevention controller 50 (e.g., storage unit 103 in FIG. 2B). The fraud prevention controller 50 also sends the layer 1 key, layer 2 key, and layer 3 key to layer 1 of the web layer (corresponding to the web application layer 45 in FIG. 2A). Layer keys such as the layer 1 key have the same function as the verification key in FIG. 2A and are used to determine whether malware has infiltrated each program. The web layer stores the layer keys such as the layer 1 key sent from the fraud prevention controller. This storage is performed by writing the layer keys into part of the program under the management of the web layer program.

[0083] At time A1, a user operates client PC 20 and enters a URL corresponding to web computer 40. This causes client PC 20 to access communication interface 44 of web computer 40 via router 31, provider 32, and router 32. When the web tier is accessed by client PC 20 and router 31, a request is made to start launching the web tier 1 program (corresponding to verification target program 204a in FIG. 2B) in the web tier (tier 1 of web application layer 45). At this time, the web tier 45 program (specifically, location information detection unit 201 in FIG. 2B) determines the location of the client PC from which the program was launched. Furthermore, web tier 1 program (specifically, location information output unit 202 in FIG. 2B) also sends location information for tier 1 to the fraud prevention controller. This allows the fraud prevention controller to obtain the location information of the web tier program.

[0084] To determine the source of the launch (origin), the web tier 45 requests location information, such as a fingerprint, from the client PC 20 running the web tier, acquires the location information of the client PC 20 and the IP address of the router 31 to which the client PC 20 is connected, and transfers them to the fraud prevention controller. That is, at time A1, the web tier 45 sends PC identification information, a public IP address, and the like to the fraud prevention controller 50. The acquired PC identification information and public IP address are used at time A3 to determine whether the fraud prevention controller 50 is infected with malware such as a virus. For convenience of explanation, this specification describes the IP address as determining location information. However, it is not necessary to use the IP address to determine location information; other information may be used as long as it can determine whether the program is local or non-local (external). Note that the program for browsing the web (corresponding to the verification target program 204a in FIG. 2B ) on the web tier 1 is not executed until the program is determined to be normal as a result of the determination at time A3.

[0085] At time A2, the fraud prevention controller 50 requests the web tier to send the tier 1 key. In response to this request, at time A3, the web tier sends the tier 1 key to the fraud prevention controller 50. The tier 1 key was already sent from the fraud prevention controller 50 to the web tier at time A0 and is stored in the web tier. If the web tier has not been tampered with by malware after the tier key was stored, the web tier can send the same tier 1 key to the fraud prevention controller 50. However, if an external client PC or the like accesses the web tier at time A1, for example, and the web tier has been tampered with by a virus or other malware, the web tier cannot send a tier 1 key that is the same as the normal tier 1 key that is stored and stored.

[0086] This point will be explained using Figure 4B. As mentioned above, at time A0 in Figure 4A, the fraud prevention controller 50 distributes hierarchical keys 50a to 50c to the programs (instances, tasks) in the Web hierarchical layer 45 (see time A0-1), and the programs in the Web hierarchical layer 45 write the received hierarchical keys 50a to 50c into their programs and retain the hierarchical keys as part of the programs (see time A0-2). The fraud prevention controller may create hierarchical keys based on location information or random numbers in the Web hierarchical layer, or may prepare a hierarchical key in advance and distribute it only when distributing a hierarchical key for the first time.

[0087] Next, at time A1 in FIG. 4A , the anti-tamper controller 50 receives PC identification information and a public IP address from the client PC 20 (see time A1-1). If the client PC 20 is malicious and malware such as a computer virus invades the Web hierarchical layer 45, at least a portion of the program files (including the hierarchical layer 1 key, etc.) will be rewritten (see time A1-2). As a result of this program file rewriting, the hierarchical keys 50a-50c will be replaced with invalid hierarchical keys 50d-50f, or the hierarchical keys themselves will be lost. This is because the malware intruder does not know the valid hierarchical keys 50a-50c and is therefore unable to retain the correct hierarchical keys 50a-50c. As a result, even if the anti-tamper controller 50 requests the Web hierarchical layer 45 to transmit hierarchical key 1 at time A3, the correct hierarchical key 1 will not be transmitted.

[0088] Returning to FIG. 4A , at time A3, when the fraud prevention controller 50 receives the hierarchical 1 key, it compares the hierarchical 1 key held by the fraud prevention controller 50 with the hierarchical 1 key transferred from the web hierarchical 45 to determine whether they are the same. If the two hierarchical 1 keys are different, the web hierarchical tier is determined to be a fraudulent instance; if they are identical, the web hierarchical tier is determined to be a normal instance. That is, if malware such as a computer virus has invaded the web hierarchical tier, it is determined to be a fraudulent instance; if malware has not invaded, it is determined to be a normal instance. That is, as described above in 3) Hierarchical Key Verification Conditions, this embodiment compares the hierarchical key held by the fraud prevention controller with the hierarchical key held by the task to be verified (in this case, a web program) to determine whether there is a risk that the task to be verified is infected with malware such as a virus. Note that at time A3, only the hierarchical key in the web hierarchical tier is checked; however, at time A7, described below, the hierarchical keys are also checked as described in 3) b) above.

[0089] At time A3, the anti-fraud controller also determines location information. As described above in 1) Exclusion of Unauthorized Locations and 2) Location-Related Conditions, in this embodiment, location information is used to determine whether access is being made from a legitimate information source (e.g., a client PC). Generally, a client PC accessing a web application is often determined to be in a local location when viewed from the entire system. If access is made from an unauthorized information source, there is a risk of infection by malware such as a virus, so in this case, execution of the web program is prohibited. Furthermore, because the anti-fraud controller also acquires location information for web tier 1, it can determine whether a legitimate program is running based on the location information of the web program's launch source.

[0090] Therefore, at time A3, the following conditions are used to determine whether malware such as a virus has infiltrated the program in the web tier, i.e., whether there is a risk that the program in the web tier is a fraudulent instance: 1) Exclusion of fraudulent locations, 2) Location-related conditions, and 3) Hierarchy key confirmation. Specifically, the determination is made using the location information and hierarchical key described above. If any of the results of the determination reveal fraud, the entire program is determined to be a fraudulent instance.

[0091] When the fraud prevention controller 50 completes its determination, it transmits the determination result to the Web tier 45 at time A4. If the determination result is a fraudulent instance, the Web tier 45 prohibits the execution of the instance (program, task). Therefore, even if malware such as a virus invades the Web tier 45, the Web program will not be executed, so the effects of the malware infection will not spread and no damage will be caused by the malware. The infected malware such as a virus can be removed using a separate virus removal program or the like.

[0092] On the other hand, if the determination result is that the instance is normal, the fraud prevention controller 50 generates new layer 1 keys to layer 3 keys using random numbers or the like based on the PC identification information of the client PC 20 and location information such as the public IP of the router 31 obtained at time A1, and sends these generated layer keys to the Web layer 45. Then, at time A5, when the Web layer 45 starts the layer 2 instance (an instance started by an instance of the Web layer), it transfers the following keys to the lower layer (an instance started by itself, in this case layer 2 started by the Web layer): a. Layer 1 key (Web layer key) b. Layer 2 key (key of its own layer (layer 2)) c. Layer 3 key (layer key for transfer to a higher layer)

[0093] At time A5, the Web layer transfers not only the Layer 1 key but also the Layer 2 and Layer 3 keys to the lower layers in order to check between the layer keys as explained in 3) b) above, thereby enabling checking for errors (infection status) at each layer. If the Web layer is contaminated by a virus or the like, program execution must be prohibited, and this is checked at the top of that layer.

[0094] At time A5, the Web tier may also transmit the PC identification information and public IP address acquired at time A1 to tier 2 in addition to the tier key. The location information of Web tier 1 may also be transmitted to tier 2.

[0095] At time A6, the fraud prevention controller 50 requests layer 2 to send the layer 1 key and layer 2 key. Note that time A6 is the timing when the web layer (layer 1) launches the layer 2 program (instance, task). In response to the request from the fraud prevention controller 50, layer 2 transfers the layer 1 key and layer 2 key at time A7. The web layer has already transferred the layer 1 key and layer 2 key to layer 2 at time A5, and layer 2 transfers these layer 1 key and layer 2 key to the fraud prevention controller 50. If the web layer (layer 1) and layer 2 are not contaminated by malware such as a virus, normal layer 1 key and layer 2 key can be transferred to the fraud prevention controller 50. The fraud prevention controller 50 may also request layer 2 to send location information of the web layer 1 that launched layer 2.

[0096] At time A7, the fraud prevention controller 50 receives the tier 1 key and tier 2 key from tier 2. The tier 2 key and tier 1 key were sent to the web tier at time A0 and are stored in the fraud prevention controller 50. The fraud prevention controller 50 compares these stored tier 1 key and tier 2 key with the tier 1 key and tier 2 key received from tier 2. If at least one of the web tier and tier 2 is not infected with malware such as a virus, the tier 1 key and tier 2 key should be the same. If the two tier keys are compared and either tier key is different, the instance is determined to be fraudulent; if the two tier keys are the same, the instance is determined to be normal. In other words, if malware such as a computer virus has infiltrated the web tier and / or tier 2, the instance is determined to be fraudulent; if no malware has infiltrated, the instance is determined to be normal.

[0097] Furthermore, at time A7, the fraud prevention controller 50 compares the layer 1 key with the layer 2 key to determine whether the layer is correct. Even if the layer 2 key is normal, if the web layer is infected with malware such as a virus, it will not be determined to be correct. Furthermore, if PC identification information and public IP address information have been received at time A5, location information can be determined.

[0098] Furthermore, if the fraud prevention controller 50 has requested that layer 2 transmit location information for Web layer 1 that started layer 2, it can determine whether layer 2 is infected with malware such as a virus by judging the location information for Web layer 1 transmitted by layer 2. In other words, if the location information indicating layer 1 does not indicate that the program in layer 2 was launched from, there is a high possibility that it has been contaminated with malware such as a virus.

[0099] Therefore, at time A7, the above-mentioned conditions of 1) exclusion of unauthorized locations, 2) location conditions, and 3) hierarchical key confirmation can be used to determine whether malware such as a virus has infiltrated the program in the Web hierarchy, i.e., whether there is a risk that the program in the Web hierarchy is an unauthorized instance.

[0100] Once the determination is complete, at time A8, the anti-tamper controller 50 communicates the determination result to layer 2. The subsequent processing is similar to the processing at time A4, except for the target. That is, if the determination result is a fraudulent instance, layer 2 prohibits the execution of the instance (program). Therefore, even if malware invades layer 2, the instance will not be executed, and the impact of the malware infection will not spread. Infected malware can be removed by another program, etc. If the instance is determined to be fraudulent, layer 2 sends an instance (program, task) termination report to the anti-tamper controller 50 at time A9 and deletes the layer 2 key. This prohibits other instances from using the layer 3 key.

[0101] If the instance is normal, at time A10, when the tier 2 instance launches the tier 3 instance (such as a database update instance), it transfers the following keys to the tier 3 instance. As mentioned above, tier 2 received the tier 1 key and tier 3 key from the Web tier (tier 1) at time A5, and transfers these tier keys to tier 3. a. tier 1 key (Web tier key) b. tier 3 key (its own tier key) In addition, tier 2 may also send location information of Web tier 1 to tier 3. The location information of Web tier 1 is information that indicates the source of the launch of the Web program.

[0102] Furthermore, after transferring the hierarchical key to hierarchical 3 at time A10, when hierarchical 3 is activated at time A11, the fraud prevention controller 50 requests hierarchical 2 to transfer the hierarchical 1 key and the hierarchical 3 key to the fraud prevention controller 50. In response to this request, hierarchical 2 transfers the hierarchical 1 key and the hierarchical 3 key to the fraud prevention controller 50. The fraud prevention controller 50 determines whether the transferred hierarchical 1 key and the hierarchical 3 key are identical to the hierarchical 1 key and the hierarchical 3 key stored in the fraud prevention controller 50. Based on this determination, if an instance (program, task) in hierarchical 3 is infected with malware, it is determined to be a fraudulent instance, and if it is not infected with malware, it is determined to be a normal instance. Furthermore, as in the case of time A7, location information determination and inter-hierarchical determination may also be performed. Furthermore, if the fraud prevention controller 50 has requested hierarchical 3 to transmit the location information of hierarchical 1 that was the basis for activating hierarchical 3, it may determine the location information transmitted by hierarchical 3.

[0103] Once the determination at time A11 is complete, although this is omitted in FIG. 4A , the fraud prevention controller 50 communicates the determination result to layer 3. If the determination result is a fraudulent instance, layer 3 prohibits the execution of the instance (program). Therefore, even if malware infiltrates layer 3, the instance will not be executed, and the impact of the malware infection will not spread. Infected malware can be removed by another program, etc. If the instance is determined to be fraudulent, layer 3 sends an instance (program, task) termination report to the fraud prevention controller 50 at time A12 and deletes the layer 3 key. This prohibits other instances from using the layer 3 key.

[0104] When all instances are terminated and the Web layer instance is also terminated, an instance termination report is sent to the fraud prevention controller 50 and all layer keys are deleted, thereby prohibiting other instances from using all layer keys.

[0105] Note that, at time A5, the explanation was given assuming that the hierarchical 1 key, hierarchical 2 key, and hierarchical 3 key created and distributed by the anti-fraud controller are held constant, but as mentioned above, these values ​​may be changed periodically or irregularly. By changing the hierarchical keys as appropriate, a robust anti-fraud mechanism can be constructed. Examples of changing the hierarchical keys will be described later using Figures 14 and 15.

[0106] Next, the verification operation during execution of a Web application (program) described using FIGS. 4A and 4B will be described for each layer and each fraud prevention controller using the flowcharts shown in FIGS. 5A to 7.

[0107] 5A and 5B are flowcharts showing the operation of Web tier 1. This flow is executed by the processor 45A and memory 45B provided in Web tier 11. In other words, it is realized by the processor in Web tier 11 executing a program stored in memory. Web tier 1 corresponds to tier 1 of Web tier 45 in FIG. 3A and to tier 1 of Web tier 45 in FIG. 4A. From another perspective, the flowchart shown for Web tier 1 is realized by the various components in the verification task 200 in FIG. 2B. Note that the program in Web tier 1 is a program that executes web browsing when accessed from client PC 20, but the web browsing operation is omitted here.

[0108] When the flow of a Web tier 1 instance begins, the tier 1 key, tier 2 key, and tier 3 key are first received from the fraud prevention controller during program installation and stored in memory within Web tier 1 (S1). This operation corresponds to the processing at time A0 in Figures 4A and 4B. At this time, each distributed tier key is written to a portion of the program (instance, task). If malware such as a virus infects the program, the virus or malware will rewrite the program, and each distributed tier key will be rewritten or lost. Note that these tier keys may be generated by the fraud prevention controller at time A0-1 in Figure 4B using location information for the Web tier and random numbers, or they may be tier keys prepared when the Web program was installed.

[0109] Next, it is determined whether PC identification information has been received from the client PC and the public IP address has been received from the router (S3). This operation corresponds to the processing at time A1 in Figures 4A and 4B. When a user wishes to view a web page via the Internet, the user inputs the URL of the web page into client PC 20. Once the URL has been input, client PC 20 accesses communication interface 44 of web computer 40 via router 31, provider 32, and router 33. At this time, identification information is sent from client PC 20 and the public IP address is sent from router 31, so in step S3 it is determined whether this information has been received. If this determination shows that the identification information and public IP address have not been received, the system enters a standby state.

[0110] If the result of the determination in step S3 is that the PC identification information and public IP address have been received, the PC identification information and public IP address are transmitted to the anti-fraud controller (S5). This operation corresponds to the processing at time A1 in Figures 4A and 4B. Even if accessed from client PC 20, the web browsing program is not launched at this point; only the PC identification information, etc. is transmitted to the anti-fraud controller. The web browsing program is executed after receiving a determination result OK signal from the anti-fraud controller in step S11 (see S13). Note that location information for web tier 1 may also be transmitted to the anti-fraud controller along with the PC identification information and public IP address.

[0111] Next, it is determined whether a request to send a hierarchical level 1 key has been received from the fraud prevention controller (S7). When the fraud prevention controller receives the PC identification information and public IP address from Web hierarchical level 1, it requests Web hierarchical level 1 to send a hierarchical level 1 key. This operation corresponds to the processing at time A2 in Figures 4A and 4B. If the determination in step S7 shows that this request has not been received, the controller enters a standby state.

[0112] On the other hand, if Web tier 1 receives a request to send the tier 1 key from the fraud prevention controller, it sends the tier 1 key to the fraud prevention controller (S9). This operation corresponds to the processing at time A3 in Figures 4A and 4B. As described above, if the instance (program, task) on Web tier 1 is not infected with malware such as a virus, the tier 1 key obtained in step S1 is retained, and this tier 1 key can be sent. However, if malware such as a virus has invaded Web tier 1, the tier 1 key obtained in step S1 is not retained, and therefore a tier 1 key identical to this tier 1 key cannot be sent. Note that, at this timing, location information for Web tier 1 may also be sent to the fraud prevention controller along with the tier 1 key.

[0113] Next, Web tier 1 determines whether it has received a judgment result OK signal from the fraud prevention controller (S11). This operation corresponds to the processing at time A4 in FIG. 4A. In step S9, when the tier 1 key is sent from Web tier 1 to the fraud prevention controller 50, the fraud prevention controller 50 determines whether the tier 1 key sent to Web tier 1 is the same as the tier 1 key sent from Web tier 1. If they are identical, the instance is determined to be normal. The fraud prevention controller 50 also determines the location information using the PC identification information and public IP address received in step S5. If the location information for Web tier 1 is a local location, the instance may be determined to be normal. If these determinations indicate that no malware such as a virus has infiltrated, the fraud prevention controller sends a judgment result OK signal to Web tier 1.

[0114] On the other hand, if the result of the determination in step S11 is that the two hierarchical keys are not identical, it is determined to be an unauthorized instance. It is also determined to be an unauthorized instance if location information such as PC identification information or public IP address is unauthorized. It may also be determined to be an unauthorized instance if the location information of Web hierarchical layer 1 is a non-local location. If these determinations determine that malware such as a virus has infiltrated, an NG signal is sent to Web hierarchical layer 1. In this step S11, it is determined whether an OK signal has been received from the fraud prevention controller 50.

[0115] If the result of the judgment in step S11 is an OK judgment result signal, the task of Web tier 1 is executed, and Web tier 1 transmits the tier 1 key, tier 2 key, and tier 3 key to tier 2 (S13). This operation corresponds to the processing at time A5 in FIG. 4A. Here, the fraud prevention controller 50 judges that the instance (program, task) of Web tier 1 is normal, so the task (program, instance), i.e., the web browsing program, is executed. In addition, the tier 1 key, tier 2 key, and tier 3 key are transmitted in preparation for starting the instance (program, task) of tier 2.

[0116] The hierarchical key transmitted at this time is the hierarchical key obtained from the fraud prevention controller 50 at time A4 in FIG. 4A . Specifically, the fraud prevention controller 50 generates a hierarchical key 1, a hierarchical key 2, and a hierarchical key 3 using random numbers or other methods based on the PC identification information of the client PC 20 and location information such as the public IP address of the router 31 obtained at time A1, and then transmits these generated hierarchical keys to the Web hierarchical layer 45 at time A4. However, if the fraud prevention controller 50 updates the hierarchical key periodically or irregularly, it transmits the updated hierarchical key. The hierarchical key transmitted in step S13 may be the hierarchical key received from the fraud prevention controller at time A0. In addition to transmitting the hierarchical key, location information for hierarchical layer 1 may also be transmitted to hierarchical layer 2. This location information can be used by the fraud prevention controller to determine whether the instance is fraudulent (normal).

[0117] After the process in step S13 is executed, it is next determined whether the instance of Web tier 1 has been completed (S17). Here, it is determined whether all instances (programs, tasks) of Web tier 1 have been executed. If all instances have been executed, it is determined that they have been completed.

[0118] Returning to step S11, if the result of the determination in this step is that an OK determination signal has not been received, execution of the task is prohibited, and transmission of the layer 1 key, layer 2 key, and layer 3 key from Web layer 1 to layer 2 is prohibited (S15). Here, the result of the determination by the fraud prevention controller 50 is that the instance (program, task) of Web layer 1 is determined to be fraudulent, that is, the instance of Web layer 1 is determined to be infected with malware such as a virus, and therefore execution of the task (program, instance) (specifically, the web browsing program) is prohibited. Furthermore, in this case, since the instance (program, task) of layer 2 will not be started, transmission of the layer 1 key, layer 2 key, and layer 3 key is also prohibited.

[0119] If the result of the determination in step S17 is that the instance of Web tier 1 has been terminated, or if the task operation has been prohibited in step S15, a task completion report is then sent to the fraud prevention controller (S19). This operation corresponds to the processing at time A13 in Figure 4A.

[0120] On the other hand, if the result of the determination in step S17 is that the instance of Web tier 1 has not been terminated, or if the processing in step S19 has been executed, the process proceeds to the above-mentioned step S3, and the processing of step S3 is executed.

[0121] In this way, when processing a Web tier 1 instance, the fraud prevention controller 50 transmits verification keys such as the tier 1 key to Web tier 1 in advance and stores these verification keys in memory (see S1). When an external client PC 20 accesses the instance (S3, S5), the fraud prevention controller 50 requests the transmission of the tier 1 key it is currently storing (S7), and transmits the tier 1 key in response to this request (S9). Based on whether these two tier 1 keys are identical, the fraud prevention controller 50 determines whether the Web tier 1 instance (program, task) is normal, i.e., whether malware such as a virus has invaded. The fraud prevention controller 50 also determines whether the location information for the client PC, etc. and tier 1 is a local location or a non-local location, and determines whether the sender is fraudulent.

[0122] When the fraud prevention controller 50 completes its determination, it transmits the determination result to the Web tier 1 (see S11). Based on the determination result, it selects whether to execute or prohibit the instance (program, task) of the Web tier 1 (see S13, S15). This makes it easy to determine whether malware such as a virus has invaded, even without a dictionary of malware such as a virus.

[0123] Furthermore, when processing a Web tier 1 instance, if it is accessed from a client PC 20, location information such as PC identification information and IP address is used to determine whether the access source is making an unauthorized access (see S3, S5). Based on the results of this determination, Web tier 1 determines whether or not to execute the task (instance, program) (see S11, S13, S15). This makes it easy to prevent the intrusion of malware such as viruses.

[0124] Next, the operation of the fraud prevention controller 50 will be described using the flowcharts shown in Figures 6A to 6C. This flow is executed by an fraud prevention controller (see, for example, the fraud prevention controller 50 in Figure 3B) provided above the Web tier 11. In other words, it is realized by the processor of the fraud prevention controller 50 executing a program stored in memory. From another perspective, the flowcharts of the fraud prevention controller shown in Figures 6A to 6C are realized by the various components within the fraud prevention controller 100 in Figure 2B.

[0125] When the fraud prevention controller flow begins, the fraud prevention control first generates a hierarchical key 1, a hierarchical key 2, and a hierarchical key 3 during program installation and sends the generated hierarchical keys to Web hierarchical key 1 (S21). This operation corresponds to the processing at time A0 in Figures 4A and 4B. These hierarchical keys are preferably generated based on location information for Web hierarchical key 1 and random numbers, as described at time A0-1 in Figure 4A. Alternatively, the fraud prevention controller 50 may prepare hierarchical keys in advance and distribute them to Web hierarchical key 1.

[0126] Next, it is determined whether PC identification information, etc. has been received from the Web tier 1 application (S23). This operation corresponds to the processing at time A1 in Figures 4A and 4B. As described above, when a user inputs a URL (Uniform Resource Locator) into the client PC 20, the Web computer 40 corresponding to this URL is accessed. At this time, Web tier 1 receives the PC identification information and public IP address, and transmits this received PC identification information, etc. to the fraud prevention controller 50. Note that location information for Web tier 1 may also be obtained at this timing. If the result of the determination in this step is that PC identification information, etc. has not been received, the system enters a standby state.

[0127] If it is determined in step S23 that PC identification information, etc. has been entered, then a request is made to Web hierarchical layer 1 to transmit a hierarchical layer 1 key (S25). This operation corresponds to the processing at time A2 in FIG. 4A. Location information may also be requested from Web hierarchical layer 1 at this timing. When a hierarchical layer 1 key is requested, Web hierarchical layer 1 transmits the hierarchical layer 1 key, and the fraud prevention controller 50 determines whether or not hierarchical layer 1 key has been received (S27). This operation corresponds to the processing at time A3 in FIG. 4A. If this determination shows that the hierarchical layer 1 key has not been received, the fraud prevention controller 50 enters a standby state.

[0128] If the result of the determination in step S27 is that a hierarchical key has been received, it is determined whether the hierarchical key previously sent to Web hierarchical key 1 is the same as the hierarchical key currently received (S29). As described above, this step determines whether the hierarchical key sent to Web hierarchical key 1 in step S21 is the same as the hierarchical key sent from Web hierarchical key 1 in step S27. If Web hierarchical key 1 is not infected with malware such as a virus, the two hierarchical key keys will be the same; if it is infected, the two hierarchical key keys will be different. If the hierarchical key has not been changed after program installation, the comparison will be with the hierarchical key at the time of installation. However, if the hierarchical key is changed at any time thereafter, the comparison will be with the changed hierarchical key.

[0129] In step S29, location information is also determined. In step S23 (corresponding to time A1 in FIG. 4A), when the web program is accessed from client PC 20, PC identification information and IP address are received. This location information is used to determine the location of the client PC from which the web program was launched. This hierarchical key determination is performed by comparing it with the location information recorded in the database (DB) at the time of unauthorized access (see S121 and S123 in FIG. 17). Furthermore, if location information for web hierarchical 1 has been obtained, it can be determined whether this location information is a local location or a non-local location to determine whether the instantiation is legitimate or unauthorized.

[0130] If the result of the determination in step S29 is that the two layer 1 keys are the same, the instance is determined to be normal (S31). On the other hand, if the two layer 1 keys are different, the instance is determined to be invalid (S33). Also, if the location information is normal (local location), the instance is determined to be normal (S31), and if the location information is invalid (non-local location), the instance is determined to be invalid (S33).

[0131] Next, the result of the determination made in step S31 or step S33 is sent to tier 1 (S35). This operation corresponds to the processing at time A4 in FIG. 4A. If the instance is normal, the fraud prevention controller creates tier keys for Web tier 1, tier 2, and tier 3 based on the location information of the client PC 20 and router 31 received in step S23 and random numbers, etc., and sends these tier keys to the Web tier. The location information of Web tier 1 may also be sent to tier 2. The tier key received by Web tier 1 is sent to a higher tier in step S41, etc.

[0132] Next, it is determined whether the result of the determination in step S29 was a normal instance (S37). If it is not a normal instance, the process returns to step S23 and repeats the above-mentioned operation. That is, execution of the program on Web tier 1 (specifically, the web browsing program) is prohibited. On the other hand, if it is a normal instance, execution of the program on Web tier 1 (the web browsing program) is permitted. Note that if a new program (instance, task) is installed on Web tier 1, execution begins from step S21.

[0133] If the result of the determination in step S37 is that the instance is normal and tier 2 has been started by Web tier 1, a request is made to tier 2 to send the tier 1 key and tier 2 key to tier 2 (S41). This operation corresponds to the processing at time A6 in Figure 4A. After the request, the system waits for tier 2 to send the tier 1 key and tier 2 key (S43). It remains in a standby state until then. This operation corresponds to the processing at time A7 in Figure 4A.

[0134] If the determination in step S43 indicates that the hierarchical level 1 key and the hierarchical level 2 key have been received, the fraud prevention controller 50 then determines whether the hierarchical level 2 key previously sent to Web hierarchical level 1 is the same as the hierarchical level 2 key currently received (S45). In step S21, the fraud prevention controller 50 determines whether the hierarchical level 2 key sent to Web hierarchical level 1 is the same as the hierarchical level 2 key sent from hierarchical level 2. If Web hierarchical level 1 is not infected with malware such as a virus, they will be the same; if it is infected, they will be different. If these hierarchical levels are generated based on the location of each hierarchical level, the controller 50 determines whether the location information sent from Web hierarchical level 1 is malicious. By checking the location of the program (instance, task) in Web hierarchical level 1, it is possible to determine whether the program is infected with malware such as a virus. In other words, the determination is based on the location information of the launch source of Web hierarchical level 2. In this case, if the location information of Web hierarchical level 1 is a local location, it is a normal instance; if it is a non-local location, it is an unauthorized instance.

[0135] If the result of the determination in step S45 is that the two layer 2 keys are the same, the instance is determined to be normal (S47). On the other hand, if the two layer 2 keys are different, the instance is determined to be invalid (S49). In addition, if the location information is also determined, if the layer 1 location information is normal, the instance is determined to be normal (S47), and if the location information is invalid, the instance is determined to be invalid (S49).

[0136] Next, the result of the determination made in step S47 or step S49 is sent to tier 2 (S51). This operation corresponds to the processing at time A8 in FIG. 4A. If the determination result is a normal instance, tier 2 sends the tier 1 key and tier 3 key to tier 3 (see time A10). At this time, location information of Web tier 1, which launched Web tier 2, may also be sent to tier 3.

[0137] Next, it is determined whether a task completion report has been received from layer 2 (S53). This operation corresponds to the processing at time A9 in FIG. 4A. In step S51, when the fraud prevention controller 50 transmits information indicating that the instance is fraudulent, the task (program, instance) in layer 2 terminates operation. In this step, it is determined whether a report has been received indicating that the task in layer 2 has completed.

[0138] If the result of the determination in step S53 is that the task in layer 2 has ended, the layer 2 key is deleted (S55). By deleting the layer 2 key, it is possible to prohibit other instances (programs, tasks) from using the layer 2 key.

[0139] If the layer 2 key is deleted in step S55, or if the result of the determination in step S53 is that a task completion report has not been received from layer 2, then layer 3 is requested to send the layer 1 key and layer 3 key to layer 3 (S57). Then, layer 3 waits for the layer 1 key and layer 3 key to be sent from layer 3 (S59). Until then, the system remains in a standby state. This operation corresponds to the processing at time A11 in FIG. 4A. In addition to the layer key, location information for the layer 3 program may also be received.

[0140] If the determination in step S59 indicates that the hierarchical key 1 and hierarchical key 3 have been received, the fraud prevention controller 50 then determines whether the hierarchical key 1 and hierarchical key 3 previously sent to Web hierarchical key 1 are the same as the hierarchical key 1 and hierarchical key 3 currently received (S61). In step S21, the fraud prevention controller 50 determines whether the hierarchical key 1 and hierarchical key 3 sent to Web hierarchical key 1 are the same as the hierarchical key 1 and hierarchical key 3 sent from hierarchical key 2. That is, if these hierarchical keys are generated based on the location of each hierarchical key, the fraud prevention controller 50 also determines whether the locations of each hierarchical key are the same. If Web hierarchical key 1 is not infected with malware such as a virus, they will be the same; if it is infected, they will be different. Furthermore, if location information for the hierarchical key 3 program (instance, task) is received, this location information can be used to determine whether the hierarchical key 3 program (instance, task) is legitimate or illegitimate. Furthermore, if location information for Web hierarchical key 1 has been obtained from hierarchical key 2, this location information can also be used to determine whether the hierarchical key 1 and hierarchical key 3 have been received. The determination is based on the location information for hierarchical key 1, which is the most recent launch source of Web hierarchical key 3.

[0141] If the result of the determination in step S61 is that the two layer 1 keys and the layer 3 key are the same, the instance is determined to be normal (S63). On the other hand, if the two layer 1 keys and the layer 3 key are different, the instance is determined to be invalid (S65). In addition, if the location information is also determined, if the location information is normal (local location), the instance is determined to be normal (S63), and if the location information is invalid (non-local location), the instance is determined to be invalid (S65).

[0142] Next, the determination result in step S63 or step S65 is sent to tier 3 (S67). Next, it is determined whether a task completion report has been received from tier 3 (S69). This operation corresponds to the processing at time A12 in FIG. 4A. In step S67, when the fraud prevention controller 50 transmits information indicating that the instance is fraudulent, the task (program, instance) in tier 3 terminates operation. In this step, it is determined whether a report has been received indicating that the task in tier 3 has been completed.

[0143] If the result of the determination in step S69 is that the task in layer 3 has ended, the layer 3 key is deleted (S71). By deleting the layer 3 key, it is possible to prohibit other instances (programs, tasks) from using the layer 3 key.

[0144] If the hierarchical level 3 key is deleted in step S71, or if the result of the determination in step S69 is that a task completion report has not been received from hierarchical level 3, a determination is made as to whether a task completion report has been received from Web hierarchical level 1 (S73). This operation corresponds to the processing at time A13 in Figure 4A. The system remains in a standby state until a task completion report is received.

[0145] If the result of the determination in step S73 is that a task completion report has been received, all hierarchical keys are deleted (S75). This prohibits other instances (programs, tasks) from using all hierarchical keys. Once all hierarchical keys have been deleted, the process returns to step S23. In step S23, when PC identification information, etc. is input from Web hierarchical layer 1, the above-mentioned operations are repeated.

[0146] Next, the operation of the tier 2 instance will be described using the flowchart shown in FIG. 7 . This flow is executed by the processor 45A and memory 45B provided in the web tier 11. That is, when tier 1 of the web tier starts tier 2, the processor in the web tier 11 executes a program stored in memory, thereby realizing the process. The web tier corresponds to the web tier 45 in FIG. 3A and the web tier in FIG. 4A, and tier 2 is the upper tier of tier 1 within this web tier. From another perspective, the flowchart shown for web tier 2 is realized by the various components in the verification task 200 in FIG. 2B. Note that the web tier 2 instance is part of a program that executes web browsing when accessed from the client PC 20, and is a program branched from tier 1. The tier 2 instance is started from tier 1, but this flow omits the web browsing operation in tier 2.

[0147] When the flow of a tier 2 instance starts, first it is determined whether Web tier 1 has started an instance of tier 2 (S81). As the program progresses, a Web tier 1 instance may start an instance of tier 2, which is below Web tier 1. Here, it is determined whether this start-up has occurred.

[0148] If the result of the determination in step S81 is that Layer 1 of the Web layer has launched an instance of Layer 2, then it is determined whether the Web Layer 1 key, Layer 2 key, and Layer 3 key have been received (S83). This corresponds to the timing A5 in FIG. 4A. Since Web Layer 1 transmits these layer keys to Layer 2 when activating Layer 2, this step determines whether they have been received. Note that location information may also be transmitted at this timing.

[0149] Next, it determines whether a request to send the layer 1 key and layer 2 key has been received from the fraud prevention controller (S85), and if so, it sends the layer 1 key and layer 2 key to the fraud prevention controller (S87). At this time, location information for Web layer 1 may also be sent to the fraud prevention controller along with the layer 1 key and layer 2 key. Based on the layer 1 and layer 2 keys and location information, the fraud prevention controller determines whether layer 2 instances (programs, tasks) are infected with malware such as viruses. The result of this determination is received from the fraud prevention controller (S89).

[0150] If the determination result in step S87 is OK, i.e., if the device is not infected with malware such as a virus, the layer 2 task (program, instance) is executed (S91), and the layer 3 key and layer 1 key are sent to layer 3 (S93). On the other hand, if the determination result is NG, i.e., if the device is infected with malware such as a virus, the layer 2 task (program, instance) is prohibited from execution (S95), and a task completion report is sent to the anti-tamper controller (S97). These operations correspond to times A7 and A8 in FIG. 4A. After executing the processing in step S93 or S97, the process returns to step S81.

[0151] As described above, the flowcharts for the instances (programs, tasks) of each tier and the fraud prevention controller shown in Figures 4A to 7 perform a verification operation to verify whether malware such as viruses has infiltrated each tier instance. Specifically, when a client PC accesses the Web tier via the Internet or the like, the fraud prevention controller 50 requests the Web tier to transmit the tier 1 key it holds (see time A2). The fraud prevention controller 50 then determines whether the tier 1 key it holds (sent to the Web tier at time A0) matches the tier 1 key transmitted from Web tier 1 at time A3 (see S29 in Figure 6A). Based on this determination, it determines whether the Web tier is a fraudulent instance or a normal instance. Therefore, in this embodiment, there is no need to maintain a dictionary containing malware such as viruses in order to determine whether the instance is infected by malware such as viruses. This eliminates the need for dictionary updates and large-capacity memory.

[0152] Furthermore, unauthorized instances function by invading from the outside and interfering with or eliminating the original instances (programs, tasks). It is generally difficult to distinguish between legitimate and unauthorized instances. Therefore, in this embodiment, attention is focused on where software on a computer should be running, and when an instance (program, task) is started, information is acquired about which instance (program, task) started the instance, as well as location information (such as the address of the program that started the instance). If this location information is a local location, the instance is determined to be legitimate; on the other hand, if the location information is a non-local location, the instance is determined to be unauthorized.

[0153] Furthermore, when accessed from a client PC 20, if the location information matches that recorded in the DB as a malicious instance, there is a high possibility that the instance (program, task) has been rewritten to become a malicious instance. Therefore, by determining the location information, it is possible to determine whether malware such as a virus has invaded. Alternatively, normal location information may be recorded in the DB, and a determination may be made as to whether the location information matches. In this manner, in this embodiment, the execution of a malicious program is prevented by determining the location from which the launched program, such as a web program, was launched.

[0154] While FIG. 4A shows layer 3 in addition to layers 1 and 2, a detailed explanation of the operation of layer 3 using a flowchart is omitted. This is because the operation of layer 3 is substantially similar to that of layer 2, and the operation of layer 3 can be easily understood based on the flowchart of FIG. 7. Even if there are layers below layer 4, like layers 1 to 3, it is possible to determine whether fraud has occurred based on location information, a layer key, etc. Furthermore, when the fraud prevention controller requests a layer key at time A2 (see FIG. 4A), step S25, etc., a specific layer key is not specified as shown in FIG. 2A. However, as in FIG. 2A, multiple layer keys of the same layer may be distributed, and the fraud prevention controller may specify a specific layer key to request transmission.

[0155] Next, the operation of the fraud prevention controller to irregularly check the validity of instances (programs, tasks) will be described using the sequence diagram shown in Figure 8. In the examples shown in Figures 4A to 7, when the client PC 20 accessed the Web computer 40, the fraud prevention controller determined whether the instance (program, task) was fraudulent or normal. Figure 8 describes an example in which the fraud prevention controller is applied to a Web program, but the invention is not limited to Web programs; it can also be applied to various programs (instances, tasks) such as user applications, management applications, and OSs.

[0156] This instance validity check determines whether there is a location mismatch between the location of the top hierarchical layer (e.g., Web hierarchical layer 1 in FIG. 4A ) and the hierarchical key of the instance being inspected (e.g., hierarchical layer 2, hierarchical layer 3, etc. in FIG. 4A ). In other words, it determines whether the verification hierarchical key distributed in advance by the fraud prevention controller matches the hierarchical key returned from each hierarchical layer. If the result of this determination is a mismatch, the instance (program, task) of the checked hierarchical layer is prohibited from execution and is forcibly terminated because malware such as a virus has invaded the instance. On the other hand, if the result of the determination is a match, the instance of the inspected hierarchical layer is normal, and the instance is executed. In other words, the execution of the inspected hierarchical layer is permitted.

[0157] A specific explanation will be given using the sequence diagram shown in FIG. 8. Note that FIG. 8 omits the distribution of the layer 1 key, layer 2 key, and layer 3 key from the fraud prevention controller 50 in FIG. 4A (see time A0). The instance validity check sequence in FIG. 4A shows the operation when a client PC accesses a Web computer. However, in the sequence diagram shown in FIG. 8, as described above, the instance validity check is performed at irregular timing within the computer. This timing is determined irregularly by the fraud prevention controller 50. Note that this timing may not be irregular or may be regular, but determining the timing irregularly provides a higher level of defense against malware infections such as viruses.

[0158] First, at time B1 (irregularly), the fraud prevention controller requests the instance on Web tier 1 to return a tier 1 key. When Web tier 1 receives this request, at time B2, it returns the tier 1 key held by Web tier 1 to the fraud prevention controller. The fraud prevention controller compares its own tier 1 key with the tier 1 key returned from Web tier 1 to determine whether they match. If they do not match, the fraud prevention controller determines that the location does not exist or is an illegal location, i.e., an illegal instance, and forcibly terminates the instance on Web tier 1. If they match, the instance on Web tier 1 is executed (permitted to run) as a normal instance. In this way, the fraud prevention controller performs a tier 1 search (instance validity check for tier 1) at regular or irregular intervals. Checking the validity of this instance at irregular intervals strengthens defense against malware such as viruses.

[0159] Similarly, at time B3 (irregular timing), the fraud prevention controller requests the layer 2 instance to return the layer 1 key. Subsequently, at time B4, the layer 2 returns the layer 1 key and layer 2 key held by it to the fraud prevention controller, and the fraud prevention controller compares the layer 1 key and layer 2 key held by it with the layer 1 key and layer 2 key returned from layer 2 to determine whether they match. Depending on the result of this determination, it determines whether the instance is fraudulent or normal. If it is fraudulent, it forcibly terminates the instance. If it is normal, the instance is executed (execution is permitted). In this way, at irregular timing, the fraud prevention controller performs a layer 2 search (instance validity check for layer 2).

[0160] Similarly, at time B5 (irregular timing), the fraud prevention controller requests the instance in layer 3 to return the layer 1 key and layer 3 key. Subsequently, at time B6, the layer 1 key and layer 3 key held by layer 3 are returned to the fraud prevention controller, and the fraud prevention controller compares the layer 1 key and layer 3 key held by itself with the layer 1 key and layer 3 key returned from layer 3 to determine whether they match. Depending on the result of this determination, it determines whether the instance is fraudulent or normal. If fraudulent, the instance is forcibly terminated. If normal, the instance is executed (execution is permitted). In this way, at irregular timing, the fraud prevention controller performs a layer 3 search (instance validity check for layer 3).

[0161] In this way, the anti-tamper controller periodically (or periodically) requests each layer to return a layer key for verification, and compares the returned layer key with the layer key it holds to determine whether the instance in each layer is a legitimate instance or an illegitimate instance. This makes it possible to determine whether each layer is infected with malware such as a virus, and to prevent malware infection. When requesting the transmission of the layer key, the anti-tamper controller may also request the transmission of location information for the top layer, and use this location information to check whether the instance is infected with malware such as a virus, i.e., to check the legitimacy of the instance.

[0162] In the example shown in Fig. 8, the validity of an instance is checked by comparing hierarchical keys. However, the validity of an instance can also be checked using location information instead of hierarchical keys. For example, the location information of the top hierarchical level can be sent to each hierarchical level, and if the location information is a local location, the instance can be determined to be normal, and if the location information is a non-local location, the instance can be determined to be invalid.

[0163] Next, the operation of preventing unauthorized instances in a user application installed in a computer will be described using the sequence diagram shown in Figure 9. The operation of preventing unauthorized instances described using Figures 4A to 7 prevented unauthorized instances in a web application. In contrast, the sequence diagram of Figure 9 shows the operation of preventing unauthorized instances in an application running inside a computer such as a personal computer PC (or a microcomputer device, a server computer, a computer in a smartphone, or a tablet computer).

[0164] This user application is executed by a processor and memory located within a computer such as a client PC 20, a tablet computer, a smartphone, or a server. That is, the user application is stored in memory, and the processor executes the user application stored in memory. Note that the user application is an application for executing a normal application, but in addition to the operation of this application, programs (instances, tasks) for executing the operations shown in Figures 9 and 10 are added. This user application is usually stored in the application layer 12 of Figure 1.

[0165] For user applications installed on a computer, the location at the time of instance startup is the local location (internal location) of the computer. However, if the instance that is started is not in the registered local location but in a location where it was started outside the computer, it can be determined to be an unauthorized instance. Therefore, unauthorized activity can be detected at the stage when a remote instance started from outside rewrites an instance (program, task) inside the computer.

[0166] This will be explained in detail using the sequence diagram shown in Figure 9. At time C0, the fraud prevention controller creates a layer 1 key and a layer 2 key based on the location information of the application layer (layer 1) and a random number, etc., and distributes these layer keys to the application layer (layer 1). Note that the same layer keys as the layer 1 key and layer 2 key recorded in the fraud prevention controller may be written to the application itself in the application layer. Alternatively, the application layer itself may create the layer 1 key and layer 2 key using its own location information and a random number, etc., and send these layer keys to the fraud prevention controller.

[0167] At time C1, when the application is launched, PC identification information is sent from the application layer to the anti-tamper controller. That is, the PC's unique location information (local location information) and the top layer instance (the instance of the Web layer) are sent to the anti-tamper controller.

[0168] Upon receiving the PC identification information, the anti-fraud controller requests the application layer to transmit a layer 1 key at time C2. Subsequently, at time C3, the application layer returns the layer 1 key to the anti-fraud controller. At this time, the anti-fraud controller determines whether the layer 1 key distributed at time C0 is the same as the layer 1 key changed at time C3. The anti-fraud controller also determines whether the PC identification information received at time C1 is location information corresponding to the application layer (layer 1). In other words, it determines whether it is local location information indicating the inside of the computer. Based on the layer key and location information, the anti-fraud controller determines whether the launched application is a fraudulent application. Having made this determination, it transmits the determination result to the application layer at time C4. The operations from time C2 to C4 are similar to the operations from time A2 to A4 in FIG. 4A , and therefore will not be described in detail.

[0169] Next, at time C5, the application layer (layer 1) launches the general DB layer (layer 2). When the top layer instance (application layer, layer 1) launches the instance of the general DB layer (layer 2), it passes the following layer keys to the layer 2 instance: a. Layer 1 key (key for the top layer) b. Layer 2 key (key for the general DB layer (its own layer)) The layer keys at this time are created using the PC identification information at the time of application launch and a random number, etc.

[0170] Next, at time C6, the fraud prevention controller requests the general DB layer (layer 2) to return the layer 1 key and layer 2 key, and receives the layer 1 key and layer 2 key at time C7. It determines whether the received layer 1 key and layer 2 key are the same as the layer key distributed at time C0, and transmits the determination result at time C8. Then, at time C9, the fraud prevention controller receives a task completion report, and at time C13, it receives another task completion report. The operations from times C5 to C9 and C13 are similar to the operations from times A5 to A9 and A13 in Figure 4A, so details will be omitted.

[0171] As described above, in the user application shown in FIG. 9 , when layer 1 of the user application is launched, the anti-fraud controller requests the application layer to return a layer 1 key. The controller determines whether the initially distributed layer key is the same as the layer key returned after the application is launched. The controller also determines whether the instance of the launched layer is a fraudulent application based on the application's location information. Based on this determination result, the controller determines whether the user application is infected with malware such as a virus. As in the other examples, after the layer key is distributed at time C0, the layer keys held by the anti-fraud controller and the application layer may be synchronized and changed. Although layer 3 is not shown in FIG. 9 , anti-fraud operations may also be performed for layer 3, as in FIG. 4A . The same applies to layers 4 and above.

[0172] Next, the fraud prevention operation in the user application layer shown in FIG. 9 will be described using the flowchart shown in FIG. 10. This flow is executed by a processor and memory provided in the application layer. That is, it is realized by a processor in the application layer executing a program stored in memory. The application layer corresponds to a computer such as a personal computer PC (or a microcomputer device, a server computer, a computer in a smartphone, or a tablet computer) (for example, in FIG. 3A, it corresponds to the processor 21 in the client PC 20, the processor 41 in the web computer 40, and the application layer 46 in the communication interface 44). From another perspective, the flowchart shown in application layer 1 is realized by the various components in FIG. 2B. Note that the program in application layer 1 is a program that executes a user application installed in the computer, but the operation of the user application is omitted here. The operation in the user application layer shown in FIG. 10 is similar to the flowchart showing the operation of web layer 1 shown in FIGS. 5A and 5B. Except for replacing steps S1-S5 in FIG. 5A with steps S1A-S5A in FIG. 10, the two are the same, so the differences will be mainly described.

[0173] When the flow for the application tier 1 instance starts, first, when the user application is installed, the tier 1 key and tier 2 key are received from the anti-fraud control and stored in memory within application tier 1 (S1A). This operation corresponds to the processing at time C0 in Figure 9.

[0174] Next, it is determined whether a user application has started (S3A). In the instance of application layer 1, when the user operates the input interface, the user application starts. If the application is not running, it enters a standby state. In addition, an application may start regardless of user operation. When the application starts, PC identification information is sent to the anti-tamper controller according to the started application (S5A).

[0175] In step S5A, the operation after sending the PC identification information to the anti-tamper controller is the same as the operation from step S7 onward in Figures 5A and 5B, and therefore a detailed explanation will be omitted. Note that the operation of the anti-tamper controller and hierarchical level 2 in the sequence diagram of Figure 9 can be achieved by appropriately modifying the processes in Figures 6A to 6C and Figure 7, and therefore a description using a flowchart will be omitted.

[0176] However, in the user application, when making the determination in step S29 of FIG. 6, it may be determined whether the user application is valid or invalid based on whether the location information received in step S23 is a local location or a non-local location.

[0177] Next, using the sequence diagram shown in FIG. 11 , we will explain the operation of preventing unauthorized instances in a management application for management installed in a computer, i.e., the operation of preventing the intrusion of malware such as viruses. The unauthorized instance prevention operation described using FIGS. 4A to 7 is intended to prevent unauthorized instances in a Web application, and the unauthorized instance prevention operation described using FIGS. 9 and 10 is intended to prevent unauthorized instances in a user application. In contrast, FIG. 11 is intended to prevent unauthorized instances in a management application. Note that when a management application is located in the Web application layer 12 (see FIG. 1 ), the process is substantially the same as the case of a user application shown in FIGS. 9 and 10 . FIG. 11 focuses on the case where the management application is located in a management layer higher than the application layer 12.

[0178] In the case of general applications, the operation of applications used by users (end users) and management applications used by administrators such as those responsible for master management is roughly the same. The location of the management application layer must be local (a location with closed privileges), and any violation of this rule is considered unauthorized. Therefore, if the location is not local, system operations such as backing up the master are considered to be illegal operations. Note that location information for management application applications is stored within the management application application.

[0179] The location information in the management application is basically included in the key information, which has the following structure: 1) Location information (local location) 2) Location random number calculated key 3) Hierarchy information (all from the top layer) 4) Hierarchy information random number calculated key This location information is stored for each running instance.

[0180] Furthermore, in the management application, as with other applications, a hierarchical key is used to determine whether fraudulent processing has occurred, i.e., whether the application is infected with malware such as a virus. That is, in the example shown in Fig. 11, when the management application is installed, the fraud prevention controller distributes a hierarchical key to the management application layer, and determines whether fraudulent operation has occurred based on whether this distributed hierarchical key matches the hierarchical key returned from the management application layer.

[0181] This management application is executed by a processor and memory arranged to execute management applications within a computer such as the client PC 20, a tablet computer, a smartphone, or a server. That is, the management application is stored in memory, and the processor executes the management application stored in the memory.

[0182] The fraud instance prevention operation in the management application for management installed in the computer shown in FIG. 11 can be compared to the fraud instance prevention operation in the user application shown in FIG. 9 by replacing the operations performed on the general DB tier (tier 2) with operations on the management DB tier (tier 3), and the operations performed by the general DB tier (tier 2) with operations performed by the management DB tier (tier 3). Furthermore, the tier 2 keys are replaced with tier 3 keys. With these substitutions, the fraud prevention instance operation in the management application shown in FIG. 11 is the same as the fraud prevention instance operation in the user application shown in FIG. 9. Furthermore, the operations at times D0 to D13 shown in FIG. 11 are substantially the same as the operations C0 to C13 shown in FIG. 9. Therefore, detailed explanations of FIG. 11 will be omitted.

[0183] 3 to 11 have described the function of preventing unauthorized intrusion of malware such as viruses into applications. Next, using FIGS. 12 and 13, a function of preventing unauthorized intrusion of malware such as viruses into OS (Operating System) drivers will be described. Here, the unauthorized intrusion of malware is prevented using the same technology as in FIGS. 3 to 11. The unauthorized intrusion of malware such as viruses is prevented in OS drivers using the same operations as those for the web applications, general applications, and management applications described above.

[0184] To prevent unauthorized intrusions by malware, the main routine (OS core instance) launched by the IPL loader (Initial Program Loader) is used as the top hierarchical instance (corresponding to hierarchical layer 1 in Figures 4A, 8, 9, and 11). The location of the OS core hierarchical layer must be local (a location with closed privileges), and any violation of this rule is considered unauthorized. Therefore, if the location is not local, system operations such as backing up the master are considered illegal. The OS location information is stored within the OS program software. In addition, the anti-tamper controller issues and compares hierarchical keys in the OS to prevent unauthorized intrusions by malware such as viruses.

[0185] The process when an OS driver is started will be described using the sequence diagram shown in Fig. 12. The OS starts various driver programs and other sub-instances under its core program. The fraud prevention function of this embodiment prevents the intrusion of malware such as viruses by executing the process shown in Fig. 12 for each sub-instance started.

[0186] The sequence diagram shown in FIG. 12 shows the operation when the OS driver is started, as described above. However, only time E0 shows the operation when the OS driver is installed before the PC is started. At time E0, the anti-tamper controller distributes a layer 1 key and a layer 2 key to the OS core layer (layer 1). As with the other examples, the layer 1 key and layer 2 key are created using location information of the OS core layer (layer 1) and random numbers, etc. The OS core layer stores the distributed layer 1 key and layer 2 key in memory within the OS layer.

[0187] At time E1, the computer (PC) is powered on and the PC boots up. At this time, the OS core layer (layer 1) boots up first. The layer 1 key and layer 2 key sent at this time are generated using location information for the OS core layer and random numbers, etc. The PC startup operation shown in FIG. 12 is substantially the same as the operation at times A1 to A5 in the sequence diagram shown in FIG. 4A. Furthermore, the operations for each driver after PC startup are also substantially the same as the operation at times A6 to A9 in the sequence diagram shown in FIG. 4A. In other words, since appropriate modifications can be made, such as replacing the OS layer with a Web layer, detailed explanations will be omitted here and only a brief description of the operation will be provided.

[0188] First, when the PC starts up, the OS core layer sends PC identification information (location information of the OS core layer) to the anti-tamper controller. Once the PC identification information is sent, the anti-tamper controller requests the OS layer to send a layer 1 key, and at time E2, the OS layer returns the layer 1 key stored in memory to the anti-tamper controller. The anti-tamper controller determines whether the layer 1 key distributed at time E0 is the same as the layer 1 key returned at time E3. If they are not the same, the OS layer determines that the instance is a fraudulent instance infiltrated by malware such as a virus, and prohibits the OS from operating. On the other hand, if the two layer 1 keys are the same, the instance is deemed normal, and the OS is permitted to operate. At this time, it may be possible to detect whether the location information of the OS core layer is a local location or a non-local location, and determine whether the instance is a fraudulent instance or a normal instance based on the detection results.

[0189] If the determination result is that the instance is normal, the OS core layer sends the layer 1 key and layer 2 key to the driver layer (layer 2) at time E5. Upon receiving the layer keys, the driver layer stores the layer 1 key and layer 2 key in memory within the layer. The fraud prevention controller also uses the PC identification information sent at time E1 to determine whether the location information is fraudulent.

[0190] Next, at time E6, the OS layer starts the driver layer, and processing for each driver begins. First, the anti-tamper controller requests the driver layer (layer 2) to send the layer 1 key and layer 2 key. In response to this request, the driver layer sends the layer 1 key and layer 2 key received and stored in memory at time E5 to the anti-tamper controller (see time E6). The anti-tamper controller determines whether the transmitted layer 1 key and layer 2 key are the same. At time E8, the anti-tamper controller sends the determination result to the driver layer. If the anti-tamper controller determines that the driver layer is normal, the instance of the driver layer is permitted to operate. On the other hand, if the anti-tamper controller determines that the instance of the driver layer is fraudulent, the instance of the driver layer is prohibited from operating. When the driver operation ends, at time E12, the driver layer sends a driver termination report to the anti-tamper controller. When the driver layer ends, the layer 2 key is deleted. This prevents the layer key from being used fraudulently.

[0191] Next, the processing when an application is launched by the OS will be described using the sequence diagram shown in Figure 13. The sequence diagram shown in Figure 13 shows not only the operations when an application is launched by OS startup, but also the operations when installing OS drivers before PC startup. Time F0 is the same as the aforementioned time E0, and the anti-tamper controller distributes the layer 1 key and layer 3 key to the OS core layer (layer 1). The OS core layer stores the distributed layer 1 key and layer 3 key in memory within the OS layer.

[0192] The operations at times F1 to F4 are those performed when the computer (PC) is started up, and are similar to the operations at times E1 to E4 in Fig. 12, so a detailed description will be omitted. Times F5 to F9 show the case where the OS runs an application. The operations here are substantially the same if the driver layer (layer 2) in the sequence diagram of Fig. 12 is replaced with the application layer (layer 3), and times E5 to E12 are replaced with times F5 to F12, so a detailed description will be omitted.

[0193] As described above, a fraud prevention controller is placed in the OS and determines whether the hierarchical keys match. If the hierarchical keys do not match, it is determined that malware such as a virus has invaded the OS, and the OS operation can be stopped, thereby preventing damage caused by malware such as a virus. Therefore, the fraud prevention controller according to this embodiment can prevent the operation of fraudulent applications from the time the OS is started. In addition, it may detect whether the location information of the OS core hierarchy is a local location or a non-local location, and determine whether the instance is fraudulent or normal based on the detection result.

[0194] Next, an operation for preventing the intrusion of malware such as viruses during a program update process will be described using the block diagrams shown in FIGS. 14 and 15 . If a program (instance, task) installed in a computer has a defect or the like, the program is rewritten from outside. There is a risk that malware such as viruses may invade from outside by utilizing this program update function. Therefore, in this embodiment, the above-described technology is applied to prevent the intrusion of malware such as viruses during a program update.

[0195] FIG. 14 shows the initial installation of a program (insta, task). Here, a storage device 54 is installed within the mother host 51, and the installation program is stored in this storage device 54. The mother host 51 also stores update keys 1 to 4 (collectively referred to as update keys 52) in its memory. Although FIG. 14 shows four update keys 52, it is assumed that n update keys are stored.

[0196] The target PC 56 is a computer to which a program (initial file) is written from the mother host 51. The computer is not limited to a desktop computer, but may also be a laptop computer, a smartphone, a tablet computer, or a server computer. The target PC 56 is provided with a storage device 59 to which the program is written.

[0197] As will be described later, the target PC 56 is also provided with an update key input unit (not shown) for inputting update keys 1 to 4 (collectively referred to as update key 57), an update key request unit (not shown) for requesting transmission of an update key when updating a file, and a memory (storage device 59) for storing update key 57. Like the hierarchical key described above, this update key has the function of determining whether malware such as a virus has invaded. The target PC 56 is also provided with an anti-fraud controller as described above (e.g., anti-fraud controller 16 shown in FIG. 1, anti-fraud controller 100 shown in FIG. 2B, anti-fraud controller 50 shown in FIGS. 3A and 3B, etc.).

[0198] 14, when the program is installed for the first time, the update key 52 stored in the mother host 51 is written as the update key 57 through the update key input unit. Then, the initial file is written from the storage device 54 in the mother host 51 to the storage device 59 in the target PC 56. Like the hierarchical key, the update key may be created based on the location information of the mother host and a random number, etc. Note that although multiple (n) update keys 57 are written to the target PC 56 in FIG. 14, a single key may be written, and a single or multiple update keys may be written for each hierarchical level.

[0199] FIG. 15 shows a method for installing an update program (insta, task) and verifying whether the program written to the target PC 56 is infected with malware such as a virus using an update key.

[0200] When updating a program stored in the target PC 56, the target PC 56 first connects to the mother host 51 (see time T1). Next, the target PC 56 randomly assigns an update key to the mother host 51 and requests the mother host 51 to send the update key via the update key request unit (see time T2). Next, the mother host 51 sends the assigned update key (update key 52a in FIG. 15) to the target PC 56 (see time T3). The target PC 53 compares the update key 57a stored in the target PC 53 with the update key 52a sent from the mother host 51 and determines whether the two keys are the same. If the mother host 51 is a normal program supplier, the returned update key should be the same.

[0201] If update key 52a and update key 57a match, then mother host 51, upon confirming that the update key is valid, transmits new update key 53 to target PC 56, which stores it as update key 58 (see time T4). Next, target PC 56 writes the update file transmitted from mother host 51 (see time T5). On the other hand, if update key 52a and update key 57a do not match, then writing of the update file is prohibited because there is a high possibility that the program is fraudulent.

[0202] As described above, in the present embodiment shown in FIGS. 14 and 15 , a computer (target PC 56) containing an anti-tamper controller can be connected to a mother host 51 that installs a task to be verified. The anti-tamper controller includes an update key input unit (see time T0) that inputs an update key when the task to be verified is initially installed (see FIG. 14 ), an update key storage unit (storage device 59) that stores the update key input in the update key input unit, and an update key request unit (see time T1) that requests the mother host to return an update key when the task to be verified is updated (see FIG. 15 ). The computer (target PC 56) also includes a determination unit that compares the update key (update key 52 a) returned from the mother host with the update key (update key 57 a) stored in the update key storage unit to determine whether the updated task to be verified is valid. Note that, in this embodiment, the anti-tamper controller of the target PC 56 may also determine whether the task is fraudulent based on location information of the mother host 51.

[0203] Next, the issuance of a hierarchical key and the process of verifying the hierarchical key will be described using Figures 16 and 17. When executing instances (programs, tasks) such as the aforementioned web applications, user applications, management applications, and OS drivers, the fraud prevention controller may issue a hierarchical key and verify the hierarchical key returned from the instance (program, task). The operations performed at this time will be described using Figures 16 and 17. These operations are primarily performed by the processor in the fraud prevention controller, memory that stores programs, etc.

[0204] First, an example of a hierarchical key issuance procedure will be described using the flowcharts shown in Figures 16A and 16B. This hierarchical key issuance procedure is executed by the fraud prevention controller 50, for example, at times A0, A5, and A10 in Figure 4A, time A0-1 in Figure 4B, S13 in Figure 5B, and S21 and S35 in Figure 6A. Note that if a hierarchical key equivalent to hierarchical level 1, such as a Web hierarchical level, has a fraud prevention function, the hierarchical key may be issued at that hierarchical level as described below. Note that the hierarchical key may remain unchanged and be changed only when a program or the like is upgraded, or may be changed irregularly or periodically.

[0205] When the flow for requesting the issuance of a hierarchical key shown in FIG. 16A begins, the location is first confirmed (S101). For example, at time A1 in FIG. 4A (see S3 in FIG. 5A), time C1 in FIG. 9 (see S5A in FIG. 10), time D1 in FIG. 11, time E1 in FIG. 12, and time F1 in FIG. 13, access occurs with location information from an external location or another internal location. If there are other PCs or servers within the local system, the other internal location is the location of these PCs, servers, etc. In the case of applications such as user applications, management applications, and operating systems, the location information storing these applications is used. In other words, whether the source of the request for issuance of a hierarchical key is legitimate or illegitimate can be determined based on whether the location information is a local location or a non-local location.

[0206] In step S101, the location information acquired at this time is confirmed. This confirmation is performed by searching the fraudulent location DB (database) 71, which stores the fraudulent locations, to see if the location information of the instance that made the fraudulent issuance request for the hierarchical key exists. In addition to searching the fraudulent location DB 71, as mentioned above, it may also be determined whether the location information is a local location or a non-local location.

[0207] Based on the location confirmation result in step S101, it is determined whether or not the location is illegal (S103). Here, if the location searched in step S101 is the same as an illegal location recorded in the database, it is determined to be an illegal location. If this determination results in an illegal location, the program is forcibly terminated (S107). Here, the program (instance, task) specified by the location accessed in step S101 is forcibly terminated, and execution of the program is prohibited.

[0208] If the result of the determination in step S103 is not an illegal location, that is, if the location is normal, a hierarchical key is issued (S105). The issuance of a hierarchical key will be described with reference to the flowchart shown in FIG. 16B.

[0209] First, location information is obtained (S111). Since the location was confirmed in step S101, the location information at this time is obtained. Next, a random number is generated (S113). Here, a hash function is applied to the timestamp of the location information obtained in step S111 to generate a random number. Next, a hierarchical key is created based on the generated random number for each requested layer (S115). The random numbers generated here are created for each requested layer. In this way, a hierarchical key is created that includes the location information. The hierarchical key created here is recorded in the issued hierarchical key storage DB (database) 73.

[0210] In the hierarchical key issuance flow, program software such as a web application, management application, and OS is installed. These software programs have a regular hierarchy and a hierarchy template, and location information is inserted into this hierarchy template. A random number is generated based on the value incorporating this location information, and a hierarchical key is created. As described above, the random number may be generated using a hash function based on the value incorporating the location information. As the location information for the OS, a unique number is assigned to identify the user when the OS is installed, and this unique number may be used. In this case, the hierarchical random number is created based on the unique number. This becomes a unique hierarchical key for the PC. The timestamp is time information when the hierarchical key is created. The hierarchical key may be created without a timestamp, but using a timestamp allows for the creation of a more secure hierarchical key. In the case of a web application, management application, etc., the location information may be an address indicating the location of the PC task being executed.

[0211] Next, the process of verifying the hierarchical key of a running program (instance, task) will be described using the flowchart shown in FIG. 17 . This verification process is executed by the anti-fraud controller 50, for example, at times A3, A7, and A11 in FIG. 4A and S29, S45, and S61 in FIG. 6A . Whether a virus or other malware has infiltrated a program can be determined by determining whether the hierarchical key is valid or invalid. If this determination is made not only when the program is launched but also during program execution, it is possible to strengthen the prevention of infection by viruses and other malware. This flow is executed by the anti-fraud controller at any time, either regularly or irregularly, during the execution of various programs (instances, tasks), such as web programs, application programs, and OSs.

[0212] When the hierarchical key confirmation flow shown in FIG. 17 starts, first, it is determined whether the hierarchical keys of the running instances are the same (S121). Here, the fraud prevention controller determines whether the hierarchical key of the running instance (program, task) matches the hierarchical key of the corresponding instance (program, task) stored in the running location DB (database) 75. Furthermore, if the hierarchical key was created using location information (see S111 in FIG. 16B), it is possible to determine whether the location information is the same by comparing the hierarchical keys. If the location information is the same, it is determined that the program (instance, task) is normal.

[0213] Next, a determination is made as to whether the instance is fraudulent (S123). Here, this determination is made based on the comparison of the two hierarchical keys performed in step S121. If the two hierarchical keys match, the instance is determined to be normal; on the other hand, if the two hierarchical keys do not match, the instance is determined to be fraudulent. The determination may also be made based on whether the location information is a local location or a non-local location. If this determination results in a fraudulent instance, the running instance is forcibly terminated (S125). Since the two hierarchical keys do not match, the location of the running instance is not normal, and malware such as a virus may have invaded. Therefore, the running instance is forcibly terminated and prohibited from further operation.

[0214] If the result of the determination in step S123 is that the instance is not invalid, i.e., if the running instance is a normal instance, the hierarchical layer to which it was moved is then confirmed (S127). In this step, it is determined whether the upper hierarchical key (if the hierarchical layer is 2, the one for hierarchical layer 1) and the lower hierarchical key belong to the same instance by comparing the locations corresponding to the keys. For example, if there are two hierarchical layers, the upper hierarchical key (i.e., the hierarchical key for hierarchical layer 1) is compared with the lower hierarchical key (i.e., the hierarchical key for hierarchical layer 2).

[0215] Next, it is determined whether the hierarchies are inconsistent (S129). Here, it is determined whether the hierarchical keys of the hierarchies are inconsistent based on the confirmation result in step S127. If the result of this determination is that they match, it is determined to be normal (S131). On the other hand, if they do not match, it is determined to be fraudulent (S133). If it is determined to be normal, it means that no malware such as a virus has invaded, so execution of the instance continues as is. On the other hand, if it is determined to be fraudulent, it means that malware such as a virus has invaded, so execution of the instance is forcibly terminated, and future operation of the instance is prohibited.

[0216] Next, the function for preventing unauthorized use of personal information will be described using Figures 18 to 20B. A system 83 having a database 85 storing a large amount of personal information is often accessed from information devices owned by users, such as mobile terminals (smartphones) 81 and PCs. In this case, even if the information device can successfully log in to the system 83, as shown in Figure 18, a user who manipulates multiple pieces of personal information 87a, 87b from an information device such as the mobile terminal 81 is suspected of unauthorized use. Even in such cases, unauthorized operations can be prevented by using the fraud prevention method of this embodiment described above.

[0217] As explained using Fig. 18, an operation in which a user's terminal (mobile terminal 81) accesses multiple pieces of personal information 87a, 87b is likely to be an illegal operation. In order to prevent such illegal operations, this embodiment implements fraud prevention as shown in Fig. 19. In this fraud prevention, the following points are taken into consideration when determining whether an operation is illegal.

[0218] 1) Combining personal information with terminal location In principle, it is illegal for a user to obtain personal information other than their own. Therefore, if the same user accesses two or more pieces of personal information, this is considered an illegal operation.

[0219] 2) Acquisition of personal information target key Currently, there is no database that can identify each piece of personal information. If there was a database that could identify each piece of personal information, it would be easy to determine whether a mobile device accessing personal information is illegal or not, but measures to prevent illegal operations are taken on the assumption that such a database does not exist.

[0220] Next, prevention of unauthorized use of personal information will be described using the sequence diagram shown in Fig. 19. Fig. 4A is a sequence diagram showing the verification operation when a web application is executed. Comparing Fig. 4A with Fig. 19, it is clear that the two are the same except that layer 3 in Fig. 4A is the DB (database) operation layer (layer 3) in Fig. 19, and the processing at time A11 in Fig. 4A is replaced by processing at times A21a and A21b. Therefore, the processing at times A21a and A21b, which differ, will be mainly described.

[0221] At time A10, when the layer 3 instance (database operation layer) is started, the layer 2 instance sends the layer 1 key and layer 3 key to layer 3. Next, at time A21a, layer 3 returns the layer 1 key, layer 3 key, and the personal information key searched in the personal information table (a table containing name and address information) to the fraud prevention controller. Personal information is recorded in database 85 (see Figure 18), and this recorded personal information is in layer 3 of system 83. When the layer 2 instance uses personal information, layer 3 is started. In response to the start of layer 3, layer 3 sends the personal information key to fraud prevention controller 50 in addition to the layer 1 key and layer 3 key at time A11 in the case of Figure 4A.

[0222] As shown in Fig. 20A, the personal information key consists of the name (name key) and member ID of the user who has accessed the system 83 using the mobile terminal 81. The member ID is assigned when the user is registered in the database. The location IP is also recorded as the personal information key. The location IP is recorded based on the identification information of the client PC (mobile terminal 81) that has accessed the system 83 at time A1.

[0223] At time A21a, when the anti-tamper controller 50 receives the personal information key from layer 3 for the first time, the anti-tamper controller checks for tampering using the layer 1 key and layer 3 key received from layer 3. As in the case of time A11, this check is made based on whether the layer 1 key and layer 3 key stored in the anti-tamper controller 50 are the same as the layer 1 key and layer 3 key received from layer 3. In other words, if they are the same, it is determined that no tampering has occurred, and if they are different, it is determined that tampering has occurred. After making the determination, the anti-tamper controller 50 saves the layer 1 key, layer 3 key, and personal information key.

[0224] If the personal information keys of the data acquired the first time and the second time are different, instances with the same location IP may be subject to unauthorized access. Time A21a is the first time a user accesses system 83. The example shown in Figure 20A shows the personal information key acquired the first time, with the name key being "TSUCHIDA", the member ID being "0000001", and the location IP being "192.168.121.1".

[0225] Time A21b represents the second or subsequent time the user accessed system 83. In the example shown in FIG. 19, the user accessed system 83 through unauthorized operations. As shown in FIG. 20B, the personal information key acquired the second time has a name key of "TANAKA," a member ID of "0000005," and a location IP of "192.168.121.1." In this example, the user who accessed system 83 for the first time impersonated "TANAKA" with member ID "0000005." However, even though the name key and member ID of the second acquired personal information key are different from those of the first time, the location IP is the same for the first and second accesses, so the fraud prevention controller 50 can determine that the access is the result of unauthorized operations. Therefore, if a personal information key already exists when receiving the hierarchical key and personal information key from hierarchical level 3, it can be recognized as manipulation of someone else's information and treated as unauthorized operations.

[0226] 18 to 20B, a computer provided in system 83 includes an anti-fraud controller (e.g., anti-fraud controller 16 shown in FIG. 1, anti-fraud controller 100 shown in FIG. 2B, anti-fraud controller 50 shown in FIGS. 3A and 3B, etc.). In the embodiment shown in FIGS. 18 to 20B, the anti-fraud controller includes a location information input unit that inputs location information and a personal information key each time the computer is accessed, a storage unit that stores the location information and the personal information key input as a pair each time the computer is accessed, and a determination unit that determines whether the source of access is fraudulent based on whether the location information and the personal information key match each time the computer is accessed. Therefore, fraudulent use can be prevented when multiple pieces of personal information 87a, 87b are manipulated from an information device such as portable terminal 81.

[0227] The above-described embodiments are merely examples of the present invention, and it goes without saying that the present invention is not limited to the embodiments.

[0228] As described above, the fraud prevention controller according to this embodiment includes a verification key generation unit (see, for example, the verification key generation unit 102) that generates a verification key, a memory unit (see, for example, the memory unit 103) that stores the verification key, a verification key distribution unit (see, for example, the verification key distribution unit 104) that distributes the verification key to the task to be verified, a verification key request unit (see, for example, the verification key request unit 106) that requests the task to be verified to return the verification key distributed by the verification key distribution unit when the task to be verified is launched, and a determination unit (see, for example, the determination unit 108) that compares the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is valid. This eliminates the need for a massive dictionary for identifying malware such as viruses, and can prevent unauthorized use of a computer even against new malware such as viruses. The verification key indicates whether a location is local or not, and can therefore be considered a type of location information.

[0229] The fraud prevention controller according to this embodiment also includes a location information input unit that inputs location information of an external device or location information of a verification target task provided within an internal device, and a determination unit that determines whether the location information input to the location information input unit is fraudulent. Therefore, if malware such as a new virus invades the verification target task, the location information is not legitimate (a value), making it easy to determine whether it is fraudulent, thereby preventing fraudulent use of the computer. The determination unit may determine that the location information input to the location information input unit is fraudulent if it is a non-local location. A device such as a PC that constitutes a system in which multiple devices (including computers) are connected, as well as software running on a local component device and the entire element consisting of the location where the software runs, are referred to as a "local location." On the other hand, an element that does not belong to a local location and has no relationship to the system is referred to as a "non-local (external) location." If the source of a program (instance, task) (the location of the program itself) or the source from which the program is launched is a non-local location, there is a risk of malware such as a virus being invaded, and the program can be determined to be fraudulent.

[0230] In addition, the verification task controller according to this embodiment has a verification key input unit that inputs a verification key distributed by the fraud prevention controller, a memory unit that stores the verification key input by the verification key input unit, a verification key request input unit that inputs a verification key request from the fraud prevention controller, and a requested verification key output unit that outputs the requested verification key from the memory unit.

[0231] In addition, the verification task controller of this embodiment has a location information detection unit that detects location information of an external device or location information of a task to be verified that is provided within an internal device, and a location information output unit that outputs the location information detected by the location information detection unit to the fraud prevention controller.

[0232] The fraud prevention controller according to this embodiment includes a processor and a memory. The processor receives location information of an external device or location information of a task to be verified within an internal device, generates a verification key based on the received location information, stores the verification key in the memory, distributes the verification key to the task to be verified, and, upon activation of the task to be verified, requests the task to return the distributed verification key. The verification key is compared with the verification key stored in the memory to determine whether the task to be verified is valid. While a single processor may be used, multiple processors may cooperate to perform the above-described processing. For example, in the block diagram shown in FIG. 2B , multiple blocks (e.g., the location information input unit 101 and the verification key generation unit 102) and other blocks (e.g., the determination unit 108) may be implemented by separate processors that cooperate with each other to realize the functionality of the fraud prevention controller.

[0233] The verification task controller according to this embodiment includes a processor and a memory. The processor detects location information of an external device or location information of a verification target task provided in an internal device, outputs the detected location information to the anti-tamper controller, inputs a distributed verification key, stores the input verification key in memory, inputs a verification key request from the anti-tamper controller, searches for the requested verification key from memory, and outputs the verification key. While a single processor may be used, multiple processors may cooperate to perform the above-described processing. For example, in the block diagram shown in FIG. 2B , multiple blocks (e.g., the location information detection unit 201 and the location information output unit 202) and other blocks (e.g., the verification task execution / prohibition unit 209) may be implemented by separate processors that cooperate with each other to realize the function of the verification target task controller.

[0234] In addition, in this embodiment, an example has been described in which programs (instances, tasks) such as web programs, user applications, and OSs are stored inside a computer. This computer may be a personal computer (PC), a laptop computer, a tablet computer, a smartphone, a server, a cloud computer, or other computer. Furthermore, the present invention can also be applied to computers that can be connected to the outside, such as the Internet of Things (IoT). For example, the present invention can be applied to various computers, including computers for controlling home appliances, industrial equipment, factory process control, logistics control, and autonomous driving automobiles. Furthermore, the present invention can be applied to computers not connected to the outside, such as computers for financial networks, FinTech, and virtual currency processing. Furthermore, the present invention can also be applied to computers that are not connected to the outside and are at risk of intrusion by malware such as viruses. In other words, the present invention can be applied to any device that requires security against malware such as viruses.

[0235] In addition, in embodiments of the present invention, all or part of the peripheral circuits of the CPU may be realized by a CPU (Central Processing Unit) and program code, or may be realized by a circuit executed by program code such as a DSP (Digital Signal Processor), or may be realized by a hardware configuration such as a gate circuit generated based on a programming language written in Verilog, or may be realized by a hardware circuit.Furthermore, part of the functions of the CPU may be realized by a circuit executed by program code such as a DSP, or may be realized by a hardware configuration such as a gate circuit generated based on a programming language written in Verilog, or may be realized by a hardware circuit.

[0236] In addition, in the embodiment of the present invention, the process is described as being executed by a processor having a CPU or the like, but the number of processors is not limited to one, and multiple processors may operate in cooperation. Furthermore, all of the components shown in FIG. 2B do not have to be located in the same processor, but may be distributed across multiple processors. In this case, it is sufficient that the sequence diagrams and flowcharts according to this embodiment are realized by the cooperation of the components.

[0237] Furthermore, among the technologies described in this specification, the controls mainly described in the flowcharts can often be set by a program, and may be stored on a recording medium or a recording unit. The recording method for this recording medium or recording unit may be recording at the time of product shipment, using a distributed recording medium, or downloading via the Internet.

[0238] Furthermore, in one embodiment of the present invention, the operation of this embodiment is explained using a flowchart, but the order of the processing procedure may be changed, any step may be omitted, steps may be added, and the specific processing content within each step may be changed.

[0239] Furthermore, even if the operational flow in the claims, specification, and drawings is explained using words expressing order such as "first" and "next" for convenience, this does not mean that it is necessary to perform the operation in this order unless otherwise specified.

[0240] The present invention is not limited to the above-described embodiments, and the components can be modified and embodied in practice without departing from the spirit of the invention. Furthermore, various inventions can be formed by appropriately combining multiple components disclosed in the embodiments. For example, some of the components shown in the embodiments may be omitted. Furthermore, components from different embodiments may be appropriately combined.

[0241] 10...Computer, 11...Web application layer, 11a...Fraud prevention controller, 12...Application layer, 12a...Fraud prevention controller, 13...Framework layer, 13a...Fraud prevention controller, 14...OS layer, 14a...Fraud prevention controller, 15...Firmware layer, 15a...Fraud prevention controller, 16...Fraud prevention controllers, 17a to 17n...Hierarchical key, 18...Task to be verified, 20...Client PC, 21...Processor, 22...Memory, 23...Input / output interface, 24...Display device, 25...Input device, 26...Communication interface, 31...Router, 32...Provider, 33...Router, 40...Web computer, 41...Processor, 42...Memory, 43...Database, 44...Communication interface, 45...Web application layer, 45A...Processor, 45B...Memory, 46...Application layer, 47...Framework layer, 48...OS layer, 49...Firmware layer, 50...Fraud Fraud prevention controller, 50A...processor, 50B...memory, 50a to 50c...hierarchical key, 50d to 50f...fraudulent hierarchy key, 51...mother host, 52 and 52a...update key, 53...target PC, 54...storage device, 56...target PC, 57 and 57a...update key, 58...update key, 59...storage device, 81...mobile terminal, 83...system, 85...database, 87a and 87b...personal information, 100...fraud prevention controller, 101...location information input unit, 102... Verification key generation unit, 103: storage unit, 104: verification key distribution unit, 105: startup information input unit, 106: verification key input unit, 107: judgment unit, 200: verification task controller, 201: location information detection unit, 202: location information output unit, 203: verification key input unit, 204: storage unit, 204a: verification target program, 205: startup information output unit, 206: verification key request input unit, 207: requested verification key output unit, 208: judgment result input unit, 209: verification task execution / prohibition unit

Claims

1. A fraud prevention controller comprising: a location information input unit that inputs location information of an external device or location information of a task to be verified that is provided in an internal device; a verification key generation unit that generates a verification key based on the location information input to the location information input unit; a memory unit that stores the verification key; a verification key distribution unit that distributes the verification key to the task to be verified; a verification key request unit that, when the task to be verified is started, requests the task to be verified to return the verification key distributed by the verification key distribution unit; and a judgment unit that compares the verification key returned from the task to be verified with the verification key stored in the memory unit and judges whether the verification task is normal.

2. The fraud prevention controller according to claim 1, wherein the determination unit determines whether the location information input to the location information input unit is fraudulent location information.

3. The fraud prevention controller according to claim 2, wherein the determination unit determines that the location information input to the location information input unit is fraudulent if the location information is a non-local location.

4. The fraud prevention controller according to claim 1, wherein the task to be verified is at least one of a web program, an application program, a management application, and an OS.

5. The fraud prevention controller described in claim 1, characterized in that the verification key request unit requests the return of the verification key stored in the memory unit during execution of the task to be verified, and the judgment unit compares the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is normal.

6. The fraud prevention controller described in claim 1, characterized in that the verification key generation unit generates multiple verification keys, the verification key distribution unit distributes the multiple verification keys to the task to be verified, and the verification key request unit specifies one of the multiple verification keys and requests the task to be verified to return it.

7. The fraud prevention controller described in claim 1, characterized in that the task to be verified has multiple hierarchies, the verification key generation unit generates a verification key for each of the multiple hierarchies, and the judgment unit uses the verification key for each hierarchical level to judge whether each hierarchical level of the task to be verified is normal.

8. The fraud prevention controller according to claim 1, characterized in that the computer in which the fraud prevention controller is stored is connectable to a mother host in which the task to be verified is installed, and the fraud prevention controller has: an update key input unit for inputting an update key when the task to be verified is installed for the first time; an update key memory unit for storing the update key inputted by the update key input unit; and an update key request unit for requesting the mother host to return an update key when the task to be verified is updated, and the determination unit compares the update key returned from the mother host with the update key stored in the update key memory unit to determine whether the task to be verified to be updated is normal.

9. The fraud prevention controller described in claim 1, characterized in that: the location information input unit inputs a personal information key along with the location information each time the computer having the fraud prevention controller is accessed; the memory unit stores the location information and the personal information key input as a pair each time the computer is accessed; and the judgment unit judges whether the source of the access is fraudulent based on whether the location information and the personal information key match each time the computer is accessed.

10. A verification task controller comprising: a location information detection unit that detects location information of an external device or location information of a task to be verified that is provided in an internal device; a location information output unit that outputs the location information detected by the location information detection unit to an anti-tamper controller; a verification key input unit that inputs a verification key distributed by the anti-tamper controller; a memory unit that stores the verification key input by the verification key input unit; a verification key request input unit that inputs a verification key request from the anti-tamper controller; and a requested verification key output unit that outputs the requested verification key from the memory unit.

11. The verification task controller according to claim 10, wherein the task to be verified is at least one of a Web program, an application program, a management application, and an OS.

12. The verification task controller according to claim 10, wherein said storage unit stores said verification key by writing said verification key into the task to be verified.

13. The verification task controller according to claim 10, wherein the verification key input unit inputs a plurality of verification keys and stores the plurality of verification keys in the memory unit, and the verification key request input unit searches for a specified one of the plurality of verification keys and returns it to the fraud prevention controller via the requested verification key output unit.

14. The verification task controller according to claim 10, characterized in that the task to be verified has multiple hierarchies, the verification key input unit inputs a verification key for each of the multiple hierarchies, and the verification key request input unit searches for the verification key for the specified hierarchies and returns it to the fraud prevention controller via the requested verification key output unit.

15. A fraud prevention method comprising: inputting location information of an external device or location information of a task to be verified that is provided within an internal device; generating a verification key based on the location information; storing the verification key in a memory unit; distributing the verification key to the task to be verified; requesting the task to be verified to return the distributed verification key when the task to be verified is launched; comparing the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is normal.

16. The fraud prevention method according to claim 15, wherein the verification target task is determined by determining whether the location information is fraudulent or not.

17. The fraud prevention method according to claim 15, wherein the task to be verified is at least one of a web program, an application program, a management application, and an OS.

18. The fraud prevention method described in claim 15, characterized in that the request for the verification key is made by requesting the return of the verification key stored in the memory unit during execution of the task to be verified, and the task to be verified is judged by comparing the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is normal.

19. The fraud prevention method described in claim 15, characterized in that when generating the verification key, multiple verification keys are generated; when distributing the verification keys, the multiple verification keys generated are distributed to the task to be verified; and when requesting the verification key, one of the multiple verification keys is specified and the verification key is requested by requesting the task to be verified to return it.

20. The fraud prevention method described in claim 15, characterized in that the task to be verified has multiple hierarchies, and when generating the verification key, a verification key is generated for each of the multiple hierarchies, and the verification key is judged by using the verification key for each hierarchical level to determine whether each hierarchical level of the task to be verified is normal.

21. The fraud prevention method described in claim 15, characterized in that a computer storing a controller that executes the fraud prevention method is connectable to a mother host that installs the task to be verified, the fraud prevention controller inputs an update key when the task to be verified is first installed, stores the input update key in an update key memory unit, and requests the mother host to return the update key when the task to be verified is updated, and judges the task to be verified by comparing the update key returned from the mother host with the update key stored in the update key memory unit to determine whether the task to be updated is normal.

22. The fraud prevention method described in claim 15, characterized in that when inputting the location information, a personal information key is input together with the location information each time a computer having a fraud prevention controller is accessed, the memory unit stores the location information and the personal information key input as a pair each time the computer is accessed, and the verification key is determined each time the computer is accessed by determining whether the source of the access is fraudulent based on whether the location information and the personal information key match.

23. A fraud prevention method for a verification task, comprising: detecting location information of an external device or location information of a task to be verified that is provided in an internal device; outputting the detected location information to a fraud prevention controller; inputting a verification key distributed by the fraud prevention controller; storing the input verification key in a memory unit; inputting a verification key request from the fraud prevention controller; and outputting the requested verification key from the memory unit.

24. The fraud prevention method for a verification task according to claim 23, wherein the task to be verified is at least one of a Web program, an application program, a management application, and an OS.

25. The anti-tampering method for a verification task described in claim 23, characterized in that when inputting the verification keys, multiple verification keys are input and the multiple verification keys are stored in the memory unit, and when a request for the verification key is input, any specified verification key from the multiple verification keys is searched for and the searched verification key is returned to the anti-tampering controller.

26. The fraud prevention method for verification tasks described in claim 23, characterized in that the task to be verified has multiple hierarchies, and when inputting the verification key, a verification key is input for each of the multiple hierarchies, and when a request for the verification key is input, the verification key for the specified hierarchies is searched for and returned to the fraud prevention controller.

27. A fraud prevention program that causes a computer capable of controlling a task to be verified to execute the following steps: input location information of an external device or location information of a task to be verified that is provided in an internal device; generate a verification key based on the location information; store the verification key in a memory unit; distribute the verification key to the task to be verified; when the task to be verified is launched, request the task to be verified to return the distributed verification key; compare the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is normal.

28. The program for preventing fraud as set forth in claim 27, wherein the task to be verified is determined by determining whether the location information is fraudulent.

29. The fraud prevention program according to claim 27, wherein the task to be verified is at least one of a web program, an application program, a management application, and an OS.

30. The fraud prevention program described in claim 27, characterized in that the request for the verification key is made by requesting the return of the verification key stored in the memory unit during execution of the task to be verified, and the task to be verified is judged by comparing the verification key returned from the task to be verified with the verification key stored in the memory unit to determine whether the task to be verified is normal.

31. The fraud prevention program described in claim 27, characterized in that when generating the verification key, multiple verification keys are generated; when distributing the verification keys, the multiple verification keys generated are distributed to the task to be verified; and when requesting the verification key, one of the multiple verification keys is specified and the verification key is requested by requesting the task to be verified to return it.

32. The fraud prevention program described in claim 27, characterized in that the task to be verified has multiple hierarchies, and when generating the verification key, a verification key is generated for each of the multiple hierarchies, and the verification key is judged by using the verification key for each hierarchical level to determine whether each hierarchical level of the task to be verified is normal.

33. The fraud prevention program described in claim 27, characterized in that the computer is connectable to a mother host on which the verification target task is installed, the fraud prevention controller inputs an update key when the verification target task is first installed, stores the input update key in an update key memory unit, and requests the mother host to return the update key when the verification target task is updated, and determines whether the verification target task to be updated is normal by comparing the update key returned from the mother host with the update key stored in the update key memory unit.

34. The fraud prevention program described in claim 27, characterized in that when inputting the location information, a personal information key is input along with the location information each time the computer is accessed, the memory unit stores the location information and the personal information key input as a pair each time the computer is accessed, and the verification key is determined each time the access is made based on whether the location information and the personal information key match, thereby determining whether the source of the access is fraudulent.

35. A fraud prevention program for a verification task, characterized in that it causes a computer capable of controlling the task to be verified to perform the following steps: detect location information of an external device or location information of a task to be verified that is provided in an internal device; output the detected location information to an fraud prevention controller; input a verification key distributed by the fraud prevention controller; store the input verification key in a memory unit; input a verification key request from the fraud prevention controller; and output the requested verification key from the memory unit.

36. The fraud prevention program for a verification task according to claim 35, wherein the task to be verified is at least one of a web program, an application program, a management application, and an OS.

37. The fraud prevention program for verification tasks described in claim 35, characterized in that when inputting the verification keys, multiple verification keys are input and stored in the memory unit, and when a request for the verification key is input, a specified one of the multiple verification keys is searched for and the searched verification key is returned to the fraud prevention controller.

38. The fraud prevention program for verification tasks described in claim 35, characterized in that the task to be verified has multiple hierarchies, and when inputting the verification key, a verification key is input for each of the multiple hierarchies, and when a request for the verification key is input, the verification key for the specified hierarchies is searched for and returned to the fraud prevention controller.

Images