Authentication Factor File

Abstract

To reduce risk of information accessed by an authentication factor file being stolen when the authentication factor file is used for authentication.SOLUTION: An authentication factor file includes a program, wherein the program causes a computer to function as: an operation detection unit for detecting the authentication factor file being operated; and an alert transmission unit for transmitting an alert when the operation detection unit detects the authentication factor file being operated.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to a technology for performing authentication using a file as an authentication factor in cyber security. [Background technology]

[0002] In recent years, cyber attacks have been increasing, and there are various cyber security methods to counter them. For example, there is a method called Deception.

[0003] In cybersecurity, deception is a cyberattack countermeasure that detects, delays, and defends against attacks by deceiving or tricking the attackers.

[0004] Multi-factor authentication is also a cybersecurity technique. Multi-factor authentication is an authentication method that requires a user to provide multiple types of authentication factors to verify their identity in order to gain access rights. There are three types of authentication factors used in multi-factor authentication: what the user knows (knowledge information), what the user has (possession information), and the user's own characteristics (biometric information). [Prior art documents] [Non-patent literature]

[0005] [Patent Document 1] JP 2019-140573 A Summary of the Invention [Problem to be solved by the invention]

[0006] In some cases, a file is used as an element of "something you have (information you possess)" in multi-factor authentication. This file is intended, for example, for the bit string of the file itself to be used as a key. Hereinafter, for convenience, this file will be called a "key file." Note that a "key file" may also be called an "authentication element file" since it uses a file as an authentication element. A "key file" is an example of an "authentication element file."

[0007] In recent years, there have been many incidents in which attackers have infiltrated internal systems / PCs and stolen confidential information from local PCs or file servers, so using a key file as proof of possession is not necessarily safe.

[0008] In addition, in many environments, it is easy to copy key files, making it difficult to distinguish between legitimate and unauthorized use of key files. It is also difficult to detect key file leaks. If key file leaks cannot be detected, there is a high risk that information accessed by the key file will be stolen.

[0009] The present invention has been made in consideration of the above points, and aims to provide a technology that makes it possible to reduce the risk of information accessed by an authentication element file being stolen when the authentication element file is used for authentication. [Means for solving the problem]

[0010] According to the disclosed technology, there is provided an authentication element file including a program, the program causing a computer to: an operation detection unit that detects that the authentication element file has been operated; an alert sending unit that sends an alert when the manipulation detection unit detects that the authentication element file has been manipulated; An authentication factor file is provided to act as the Effect of the Invention

[0011] According to the disclosed technology, when an authentication element file is used for authentication, a technology is provided that makes it possible to reduce the risk of information accessed by the authentication element file being stolen. [Brief description of the drawings]

[0012] [Figure 1] 1 is an overall configuration diagram of a system according to an embodiment of the present invention; [Diagram 2] FIG. 11 is a functional configuration diagram of a key file (program) in the second embodiment. [Diagram 3] FIG. 11 is a sequence diagram of a process according to the second embodiment. [Figure 4] FIG. 11 is a functional configuration diagram of a server 400 according to a third embodiment. [Diagram 5] FIG. 11 is a sequence diagram of a process according to the third embodiment. [Figure 6] FIG. 13 is a functional configuration diagram of a server 500 according to a fourth embodiment. [Figure 7] FIG. 13 is a sequence diagram of a process according to the fourth embodiment. [Figure 8] FIG. 2 illustrates an example of a hardware configuration of the apparatus. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present invention (the present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0014] In this embodiment, a key file in a file format that is not normally intended for use as a key file is used as one of the authentication elements, thereby diverting the attention of third parties (especially malicious attackers) when the key file is leaked and reducing the risk that the leaked key file will be used as an authentication element.

[0015] In addition, in this embodiment, the leakage of a key file is detected by using a file operation performed by a third party (especially a malicious attacker) on the key file as a trigger, or by using information obtained by the file operation.

[0016] Any of the above measures can reduce the risk of information accessed by the key file being stolen. This embodiment will be described in more detail below.

[0017] In this embodiment, the key file is an example of "something you have (information you possess)" in multi-factor authentication, and its original function is assumed to be that the bit string of the "file" as the key file is used as information for authenticating a user (or a user terminal). However, this is not limited to this. Also, the key file may be used for authentication using one authentication factor, rather than multi-factor authentication.

[0018] (System configuration example) An example of a system configuration according to this embodiment is shown in Fig. 1. In Fig. 1, a user terminal 100 and a data management device 200 are shown as an example of an authentication system that performs authentication using a key file held by the user terminal 100. The user terminal 100 may be called an authentication request device, and the data management device 200 may be called an authentication device.

[0019] Furthermore, the attacker terminal 300 is a terminal that steals and holds a key file that was held in the user terminal 100. The attacker terminal 300 is connected to a network such as the Internet, and is therefore capable of communicating with each of the server 400, the server 500 (SaaS), and the administrator terminal 600 via the network. The server 400, the server 500 (SaaS), and the administrator terminal 600 are shown as examples of devices that make up a system for detecting the leakage of a key file.

[0020] The server 400 is, for example, a computer that stores information to be accessed. The information to be accessed may be false information to deceive an attacker. The server 500 (SaaS) is a computer that provides SaaS services. The administrator terminal 600 is a computer that displays alerts, etc.

[0021] The user terminal 100 is, for example, a terminal such as a smartphone or a PC, and the data management device 200 is a server that stores information to be accessed (e.g., a password). The data management device 200 may be a virtual machine on a cloud. The user terminal 100 and the data management device 200 are connected via a network, and are capable of communicating with each other.

[0022] Here, an example is shown in which the user terminal 100 accesses the data management device 200 connected via a network to acquire information, but this is just one example. The user terminal 100 may be provided with a function equivalent to the data management device 200. In that case, the communication between the user terminal 100 and the data management device 200 described below may be regarded as communication within the user terminal 100.

[0023] The user terminal 100 has a key file generation unit 110, an authentication request unit 120, and a key file storage unit 130. The data management device 200 has an authentication unit 210 and a data storage unit 220. The user terminal 100 has a key file as "something it has (possessed information)" in multi-factor authentication.

[0024] For example, in the user terminal 100, the key file generation unit 110 generates a key file and stores the generated key file in the key file storage unit 130. When the key file is generated, the key file may be sent to the data management device 200, and the key file may be registered as authentication information of the user terminal 100 in the data management device 200. Alternatively, the data management device 200 may generate a key file and transmit the key file to the user terminal 100.

[0025] As described later, the key file in this embodiment has a general file format whose contents appear to have meaning, so that, for example, a general application (such as a word processing application, a spreadsheet application, a presentation application, or a file compression application) provided in a PC or the like can be used as the key file generating unit 110. Note that a file created by a word processing application, a spreadsheet application, a presentation application, or the like may be called a "document file."

[0026] (Normal operation example) First, with reference to FIG. 1, an example of operation when a key file is properly used as an authentication element will be described.

[0027] When the user terminal 100 retrieves information stored in the data storage unit 220 of the data management device 200, the authentication request unit 120 of the user terminal 100 reads the key file from the key file storage unit 130 and transmits the read key file to the data management device 200.

[0028] In the data management device 200, when the authentication unit 210 confirms (authenticates) that the key file is information owned by the user (user terminal 10), it reads the information from the data storage unit 220 and transmits it to the user terminal 100.

[0029] Furthermore, in the case where the information stored in the data storage unit 220 is encrypted by the key file, the authentication unit 210 may decrypt the encrypted information by the key file, and if the decryption is successful, transmit the decrypted information to the user terminal 100. In this way, the fact that the encrypted information can be decrypted by the key file held by the user terminal 100 is an example of successful authentication of the user terminal 100.

[0030] In the above example, only the key file is used as an authentication element for obtaining information, but this is just one example. In addition to the key file, authentication may be performed using a password, ID, or PIN number. Also, in addition to the key file, fingerprint authentication or face authentication may be performed.

[0031] Below, examples 1 to 4 will be described as more specific examples. Example 1 is an example of reducing the risk that a key file will be used as an authentication element when the key file is leaked from the user terminal 100 to a third party (e.g., attacker terminal 300). Examples 2 to 4 are examples of detecting the leakage of a key file. Note that Examples 1 to 4 can be implemented in appropriate combination. Also, Examples 2 to 4 assume the use of the key file described in Example 1.

[0032] Example 1 Example 1 includes the following Examples 1-1 to 1-3.

[0033] <Example 1-1> In Example 1-1, a file in a format that is not normally intended for use as a key file is used as a key file in the user terminal 100 and the data management device 200 shown in Fig. 1. In other words, the key file generating unit 110 generates a file in a format that is not normally intended for use as a key file.

[0034] Examples of file formats that are not normally intended to be used as key files include password-encrypted compressed files (e.g. zip files), password-locked Office files (document files), PDF files, etc. These are examples of file formats that make the contents of the key file appear meaningful to anyone other than the owner of the key file.

[0035] <Example 1-2> In addition, the file name of the key file may include information that an attacker would be interested in (eg, server information, authentication information).

[0036] <Example 1-3> In addition, the contents of the key file (e.g., text in a word processing document file) may include information that an attacker would be interested in (e.g., server information such as a URL, authentication information such as an ID and password, credit card numbers, account numbers).

[0037] As in Examples 1-2 and 1-3, by including content that an attacker is interested in in the file name or file contents, it is possible to direct the attacker's interest to the contents of the key file rather than the existence of the key file as an authentication factor.

[0038] By using the key file described in the above Examples 1-1 to 1-3, the key file itself has meaning to the owner (the user of the user terminal 100), but the contents of the key file appear to have meaning to others. Therefore, when the key file is leaked, the risk that the key file will be used as one of the authentication elements can be reduced, and as a result, the risk that information accessed by the key file will be stolen can be reduced. In addition, by encrypting the file with a password, it is possible to improve the effect of making the contents seem more important and the effect of delaying access to information.

[0039] Each of the embodiments 1-1 to 1-3 may be implemented alone, or any two or all of them may be combined. All of the key files described in the embodiments 1-1 to 1-3 can be generated by the key file generating unit 110 of the user terminal 100.

[0040] The key file described in the first embodiment may be called a misdirectional file. The key file described in the first embodiment with the leak detection function described in the following second to fourth embodiments may be called a misdirectional file with leak detection function.

[0041] Hereinafter, examples 2 to 4 will be described as examples in which leakage of a key file is detected using a file operation or the use of information obtained by the file operation as a trigger.

[0042] In all of the second to fourth embodiments, it is assumed that the key file described in the first embodiment is used. In other words, it is assumed that when an attacker illegally obtains a key file, the attacker does not recognize the key file as an authentication element, but recognizes that the contents of the key file have meaning, and performs an operation to open the key file. However, in all of the second to fourth embodiments, the use of the key file described in the first embodiment is not limited to this.

[0043] (Example 2: Detection using a program with notification function) Next, a description will be given of a second embodiment. In the second embodiment, a key file in which a program with a notification function is embedded is generated by the key file generating unit 110. The embedded program may be a script, a macro, or another program.

[0044] Fig. 2 shows an example of the configuration of the key file 10 in the second embodiment. The configuration shown in Fig. 2 may be considered as the configuration of a program incorporated in the key file. More specifically, Fig. 2 shows the functional configuration realized by the program on a terminal (computer) on which the program is executed.

[0045] 2, the key file 10 has an operation detection unit 11 and an alert sending unit 12. The operation detection unit 11 detects an operation on the key file 10 on the terminal on which the key file 10 is held (e.g., double-clicking with a mouse to open the key file 10). The alert sending unit 12 is triggered by the detection of an operation on the key file 10 by the operation detection unit 11, and sends an alert (warning message) to the administrator terminal 600.

[0046] An example of the operation of the second embodiment will be described with reference to the sequence diagram of Fig. 3. Here, it is assumed that the key file 10 is leaked from the user terminal 100, and the attacker terminal 300 holds the key file 10.

[0047] In S101, the key file 10 is operated on the attacker terminal 300. As a result, the operation detection unit 11 detects the operation, and the alert transmission unit 12 generates an alert (S102) and transmits the alert to the administrator terminal 600 (S103).

[0048] In S104, an alert is displayed on the display of the administrator terminal 600. This allows the user (administrator) of the administrator terminal 600 to determine that the key file 10 has been leaked. In S104, for example, information on the original owner of the key file 10, the IP address and physical location (if obtainable) of the attacker terminal 300 where the key file 10 has been fraudulently manipulated, etc. may be displayed.

[0049] (Example 3: Detection by access to server) Next, a third embodiment will be described. In the third embodiment, a key file is generated by the key file generating unit 110, which contains server information (e.g., URL) that serves as a storage location for information that an attacker attempts to steal (e.g., authentication information such as a password). The server information may be contained in the key file, or the name of the key file may include the server information.

[0050] In the third embodiment, the server 400 in the system configuration of Fig. 1 is where the information is stored. The information actually stored in the server 400 may be false authentication information, not real authentication information. The server 400 monitors access to the server 400, and when access occurs, it determines that the key file has been leaked and sends an alert. The server 400 is, for example, a web server or a file server open to the Internet.

[0051] 4 shows an example of a functional configuration of the server 400 in the embodiment 3. As shown in FIG.

[0052] The access detection unit 410 detects access to the server 400 based on the server information written in the key file. The alert sending unit 12 is triggered by the access detection unit 410 detecting an access to the server 400, and sends an alert (warning message) to the administrator terminal 600. The data storage unit 430 stores, for example, false authentication information.

[0053] An example of the operation of the third embodiment will be described with reference to the sequence diagram of Fig. 5. Here, it is assumed that a key file is leaked from the user terminal 100 and that the attacker terminal 300 holds the key file.

[0054] In S201, the key file is opened on the attacker terminal 300, and the attacker checks the storage location of the authentication information. Here, as an example, it is assumed that the access information (URL, etc.) to the server 400 is described as the storage location.

[0055] An attacker intends to fraudulently obtain authentication information, and in S202, the attacker accesses the server 400, for example, by clicking on a URL.

[0056] When the access detection unit 410 of the server 400 detects an access to the server 400 in S203, the alert transmission unit 420 generates an alert (S204) and transmits the alert to the administrator terminal 600 (S205).

[0057] In S206, an alert is displayed on the display of the administrator terminal 600. This allows the user (administrator) of the administrator terminal 600 to determine that the key file has been leaked. In S206, for example, information on the original owner of the key file, the IP address and physical location (if obtainable) of the attacker terminal 300 where the key file has been illegally operated, etc. may be displayed.

[0058] (Example 4: Detection by attempting to log in to a service) Next, a fourth embodiment will be described. In the fourth embodiment, the key file generating unit 110 generates a key file in which authentication information for using a service provided by SaaS is described. SaaS is software (applications) provided by the cloud. An example of a SaaS service is a free-to-use email service (e.g., Gmail (registered trademark)).

[0059] The authentication information written in the key file is, for example, authentication information such as an ID and password for using a SaaS email service. The authentication information is authentication information for a dummy account to deceive an attacker.

[0060] In the fourth embodiment, the server 500 in the system configuration of Fig. 1 provides a SaaS service. The above authentication information is registered in the server 500, and when a login attempt using the authentication information is detected, a login notification is sent to the administrator terminal 600.

[0061] 6 illustrates an example of a functional configuration of the server 500 in the embodiment 3. As illustrated in FIG. 6, the server 500 includes a login detection unit 510 and a login notification unit 520.

[0062] The login detection unit 510 detects a login based on the authentication information written in the key file. The login notification unit 520 is triggered by the detection of a login attempt by the login detection unit 510, and sends login notification information notifying the administrator terminal 600 that a login attempt is being made.

[0063] The function of detecting login attempts as described above and sending a login notification is a function that is generally provided in SaaS messaging services, etc.

[0064] An example of the operation of the fourth embodiment will be described with reference to the sequence diagram of Fig. 7. Here, it is assumed that a key file is leaked from the user terminal 100 and the attacker terminal 300 holds the key file.

[0065] In S301, the key file is opened on the attacker terminal 300, and the attacker checks the authentication information of the SaaS service (eg, email service).

[0066] The attacker intends to use the authentication information fraudulently, and in S302 attempts to log in to the service (i.e., the server 500) using the authentication information written in the key file. Here, for example, the attacker enters an ID and password into a Web page displayed on the attacker terminal 300 by the server 500, and performs a send operation.

[0067] In S303, when the login detection unit 510 of the server 500 detects an attempt to log in to the server 500, the login notification unit 520 issues a login notification (S304).

[0068] In S305, an alert is displayed on the display of the administrator terminal 600. This allows the user (administrator) of the administrator terminal 600 to determine that the key file has been leaked. The alert displayed in S305 may be the login notification information of the SaaS service itself, or may be information clearly stating that the key file has been leaked.

[0069] In S305, for example, information about the original owner of the key file, the IP address and physical location (if obtainable) of the attacker terminal 300 where the key file has been illegally manipulated, and the like may be displayed.

[0070] (Hardware configuration example) The user terminal 100, data management device 200, attacker terminal 300, server 400, server 500, and administrator terminal 600 (collectively referred to as "devices") can all be realized, for example, by having a computer execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0071] That is, the device can be realized by executing a program corresponding to the processing performed by the device, using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0072] Fig. 8 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 8 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are connected to one another via a bus BS. Note that some of these devices may not be included. For example, a device that does not perform display may not include the display device 1006.

[0073] The program for realizing the processing on the computer is provided by a recording medium 1001 such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0074] The memory device 1003 reads out and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes the functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network. The display device 1006 displays a GUI (Graphical User Interface) or the like according to a program. The input device 1007 is composed of a keyboard and mouse, buttons, a touch panel, or the like, and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0075] (Effects of the embodiment) With the technology described above, when a key file is leaked, it is possible to avoid or delay the use of the key file as an authentication element. Also, it is possible to detect the leakage of the key file. Therefore, it is possible to reduce the risk of information accessed by the key file being stolen.

[0076] (Summary of the embodiment) This specification discloses at least the following authentication system, authentication element file, server, leak detection method, and program. (Section 1) an authentication request device that transmits an authentication element file; an authentication device that performs authentication using the authentication element file, The authentication element file is a file in a format that makes the contents of the authentication element file appear meaningful to a person other than the owner of the authentication element file. Authentication system. (Section 2) The authentication element file is a password-encrypted compressed file or a password-locked document file. 2. An authentication system as described in paragraph 1. (Section 3) An authentication element file used in the authentication system described in paragraph 1 or paragraph 2. (Section 4) An authentication element file including a program, the program causing a computer to: an operation detection unit that detects that the authentication element file has been operated; an alert sending unit that sends an alert when the manipulation detection unit detects that the authentication element file has been manipulated; The authentication factor file to act as. (Section 5) A server for detecting leakage of an authentication element file, an access detection unit that detects access to the server based on information written in the authentication element file; an alert sending unit that sends an alert when the access is detected by the access detection unit; A server comprising: (Section 6) A method for detecting leakage of an authentication element file used for authentication in an authentication system, comprising: A file describing authentication information for using a service provided on a network is used as the authentication element file, When the server providing the service detects a login attempt using the authentication information, the server transmits a login notification to an administrator terminal. Leak detection methods. (Section 7) A program for causing a computer to function as a server for detecting leakage of an authentication element file, the program comprising: an access detection unit that detects access to the server made based on information written in the authentication element file; an alert sending unit that sends an alert when the access is detected by the access detection unit; A program to function as a

[0077] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0078] 10 Key files 11 Operation detection unit 12 Alert sending section 100 user terminals 110 Key File Generator 120 Authentication Request Section 130 Key File Storage 200 Data management device 210 Authentication Department 220 Data Storage Unit 300 Attacker's terminal 400 Servers 410 Access detection unit 420 Alert sending unit 430 Data Storage Unit 500 servers 510 Login detection unit 520 Login notification section 600 Administrator terminal 1000 Drive Device 1001 Recording media 1002 Auxiliary storage 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input Device 1008 Output device

Claims

[Claim 1] An authentication element file including a program, the program causing a computer to: an operation detection unit that detects that the authentication element file has been operated; an alert sending unit that sends an alert when the manipulation detection unit detects that the authentication element file has been manipulated; The authentication factor file to act as.

Images