Information processing apparatus, information processing method, and recording medium recording information processing program

An information processing apparatus includes: a memory; and a processor coupled to the memory and configured to: generate, when a browser is coupled to an authenticator, unique identification information by using information acquired from the browser; verify, by referring to a first list storing identification information of a browser permitted to be coupled, whether or not the identification information is stored in the first list, store a verification result in the memory while linking with the identification information, and transmit a verification completion notification to the browser; acquire, by receiving unique identification information generated by the authenticator using the information acquired from the browser, the verification result linked with the identification information from the memory; and transmit the acquisition result to the authenticator that controls coupling propriety with the browser.

CROSS-REFERENCE TO RELATED APPLICATION

This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2019-172736, filed on Sep. 24, 2019, and the Japanese Patent Application No. 2018-228785, filed on Dec. 6, 2018, the entire contents of which are incorporated herein by reference.

FIELD

The embodiment discussed herein is related to an information processing apparatus, an information processing method, and a recording medium.

BACKGROUND

There is an existing case where identification is performed for logging into services via the Internet, such as online banking or net shopping.

Japanese Laid-open Patent Publication No. 2009-118110 is an example of related art.

SUMMARY

According to an aspect of the embodiments, an information processing apparatus includes: a memory; and a processor coupled to the memory and configured to: generate, when a browser is coupled to an authenticator, unique identification information by using information acquired from the browser; verify, by referring to a first list storing identification information of a browser permitted to be coupled, whether or not the identification information is stored in the first list, store a verification result in the memory while linking with the identification information, and transmit a verification completion notification to the browser; acquire, by receiving unique identification information generated by the authenticator using the information acquired from the browser, the verification result linked with the identification information from the memory; and transmit the acquisition result to the authenticator that controls coupling propriety with the browser.

DESCRIPTION OF EMBODIMENTS

For example, new online authentication technology using biometric authentication or the like is being standardized by Fast Identity Online Alliance (FIDO Alliance), and is adopted in online banking services and the like. In the authentication method for which standardization is advanced by the FIDO Alliance, secure authentication is realized, by a combination of local authentication using biometric information or the like and signature verification by public key cryptography via a network, without flowing confidential information such as the biometric information to the Internet. The local authentication means authentication performed, while holding registration data in an external authenticator (local) such as a terminal or a smartphone used by a user, in the terminal or the external authenticator.

For example, when accessing an authenticator from the JavaScript (registered trademark) of a browser to perform biometric authentication in authentication compliant with FIDO 2.0, it is possible to be coupled to the authenticator via a bridge interface such as Universal Serial Bus (USB)/Bluetooth (registered trademark) Low Energy (BLE)/Near Field Communication (NFC) using a Client-to-Authenticator Protocol (CTAP).

However, when the browser is coupled to the authenticator via the bridge interface as described above, a malicious application may access and attack the authenticator by the CTAP protocol. To suppress this, it is possible to request PIN input from the user at the time of CTAP coupling to authenticate a coupling source, but there is a risk that the convenience of the user may be reduced due to increase in time and effort.

In one aspect, an information processing apparatus, an inform ion processing method, and a recording medium, capable of suppressing an authenticator from being coupled from an unauthorized program may be provided.

An authentication system according to an embodiment will be described below in detail with reference toFIG. 1toFIG. 12B.FIG. 1is a diagram illustrating an example of a configuration of an authentication system10according to an embodiment.

As illustrated inFIG. 1, the authentication system10of the embodiment includes a terminal device100as an information processing apparatus, an external authenticator400, a providing server200, and an authentication server300. In the authentication system10, the number of terminal devices100, external authenticators400, providing servers200, and authentication servers300is not limited, and the arbitrary number of terminal devices100, external authenticators400, providing servers200, and authentication servers300may be included. The terminal device100and the providing server200are, the terminal device100and the authentication server300are, and the providing server200and the authentication server300are communicably coupled to each other via a network N. As the network N, any type of communication network such as a local area network (LAN) and a virtual private network (VPN) which may be wired or wireless as well as the Internet may be adopted. Communication performed via the network N may be encrypted by, for example, Transport Layer Security (TLS)/Secure Sockets Layer (SSL) or the like. The terminal device100and the external authenticator400are coupled to each other through near-field communication (NFC), Bluetooth (registered trademark) Low Energy (BLE), Universal Serial Bus (USB), or the like.

The authentication system10is one example of a system in which, when using a service provided by the providing server200in the terminal device100, biometric information is collated in the external authenticator400to perform user authentication processing, and an authentication result thereof is transmitted to the authentication server300via the terminal device100, whereby user authentication of the terminal device100is performed. The terminal device100is an information processing apparatus for the user to use the service provided by the providing server200. It is assumed that the terminal device100is, for example, a stationary personal computer or the like which does not include a biometric sensor or the like and the external authenticator400is, for example, a smartphone having a fingerprint sensor or the like.

FIG. 2is a diagram illustrating user authentication processing performed by the authentication system10. As illustrated inFIG. 2, in the authentication system10, (1) the external authenticator400generates a new key pair (public key, private key) at the time of registration to an online service, the private key is held by the external authenticator400, and the public key is registered in the authentication server300in advance. Next, (2) when a log-in request is made from the terminal device100, (3) the authentication server300transmits a challenge code to the external authenticator400via the terminal device100. Next, (4) when the terminal device100issues a log-in request to the user, (5) the user performs biometric authentication using a fingerprint sensor or the like of the external authenticator400. At this time, the external authenticator400performs authentication (local authentication) by using biometric data held in the external authenticator400, and in a case where the authentication is successful, (6) signs the challenge code with the private key, and transmits the challenge code with the signature to the authentication server300via the terminal device100. (7) The authentication server300performs authentication by verifying the challenge code with the signature with the public key, and in a case where the authentication is successful, permits log-in of the user. In the embodiment, since the user authentication processing as described above is performed, it is not required to flow confidential information such as biometric information through the network N, and thus secure authentication may be performed.

The authentication system10of the embodiment has a function of suppressing access to the external authenticator400from an unauthorized program (application) installed in the terminal device100, separately from the function of performing the user authentication processing described above. Hereinafter, the function of suppressing the access to the external authenticator400from the unauthorized program will be mainly described.

FIG. 3illustrates a configuration of each device included in the authentication system10. As illustrated inFIG. 3, in the terminal device100, for example, a client application (Relying Party application)22of the JavaScript or the like acquired by a browser20from the providing server200is executed on the browser20. The Relying Party application22includes an authentication library (Polyfill)24by the JavaScript or the like, and the Polyfill24performs inter-process communication with a measurement application (Platform application)26operating on an operating system (OS). The Platform application26controls coupling to the external authenticator400via a bridge interface28using information acquired from an API (Platform API) of the OS.

The external authenticator400includes a CTAP coupling interface40, a key management unit42, a signature unit44, a graphical user interface (GUI) control unit46, a data generation unit48, and a biometric authentication library50.

The CTAP coupling interface40is coupled to the terminal device100through the bridge interface28using the CTAP protocol. The CTAP protocol is a protocol, which is adopted from the FIDO 2.0, for accessing an authenticator.

The key management unit42manages the private key. The key management unit42may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2) and a private key used to suppress access to the external authenticator400, or may manage a common private key usable for each processing.

The signature unit44executes signature processing when caller application information is transmitted together with a signature request from the bridge interface28. In this signature processing, the signature unit44uses the private key managed by the key management unit42. In the user authentication processing (FIG. 2), when the authentication OK determination is made by the data generation unit48, which will be described later, the signature unit44attaches a signature to the challenge code using the private key for authentication managed by the key management unit42. The signature unit44transmits the challenge code with the signature to the authentication server300via the terminal device100.

The GUI control unit46displays an input dialog for the biometric authentication. The data generation unit48generates collation data from the image acquired from a biometric sensor. In the user authentication processing (FIG. 2), the data generation unit48compares biometric data stored in the biometric authentication library50and the generated collation data with each other, and determines authentication OK/NG.

The providing server200is a server that provides various services. When receiving a service request from the terminal device100, the providing server200transmits a Web application to the terminal device100, and provides various services to the user after the user authentication by the authentication server300.

The authentication server300is a server for processing an authentication request received from the terminal device100. The authentication server300includes a verification unit60illustrated inFIG. 3. When acquiring information with the signature from the external authenticator400via the terminal device100, the verification unit60executes verification using the public key, and transmits the verification result to the terminal device100. In the terminal device100, when the verification result that the browser to be coupled to the external authenticator400is appropriate is obtained, the terminal device100is notified that access to the external authenticator400from the browser20is permitted. With this, the access to the external authenticator400from the unauthorized program is controlled. The authentication server300may, as the public key, separately manage a public key used for the above-described authentication processing (FIG. 2) and a public key used to suppress the unauthorized access to the external authenticator400, or may manage a common public key usable for each processing.

FIG. 4illustrates a functional block diagram of the terminal device100. As illustrated inFIG. 4, the Polyfill24includes a server verification cooperation unit242as a transmission unit, and an ID acquisition unit244. The Platform application26includes an ID issuing unit262as a management unit, an application information acquisition unit264, and an ID verification unit266as an acquisition unit. The bridge interface28includes a signature request unit282as a request unit, and an application information acquisition request unit284.

The server verification cooperation unit242exchanges information in cooperation with the verification unit60of the authentication server300.

When the browser20is coupled to the external authenticator400, the ID acquisition unit244exchanges information with the Platform application26, and acquires an identity certification ID issued by the ID issuing unit262of the Platform application26. The ID acquisition unit244transmits a signature request to the signature request unit282of the bridge interface28by using the acquired identity certification ID.

The ID issuing unit262acquires a process ID of the browser20, ands transmits the process ID to the application information acquisition unit264. The ID issuing unit262issues an identity certification ID based on information (process name) of the caller application transmitted from the application information acquisition unit264, and notifies the ID acquisition unit244thereof. The ID issuing unit262manages the identity certification ID, the process name, and the process ID in a management information table80as a storage unit illustrated inFIG. 10A.

The application information acquisition unit264acquires the caller application information (process name) based on the process ID received from the ID issuing unit262, and notifies the ID issuing unit262thereof.

When receiving the acquisition request of the caller application information (process name) from the application information acquisition request unit284of the bridge interface28, the ID verification unit266refers to the management information table80and verifies the identity certification ID included in the acquisition request. The ID verification unit266acquires the process name corresponding to the identity certification ID from the management information table80, acquires application information (front display application information) that is being executed at the forefront surface of the terminal device100, and notifies the application information acquisition request unit284thereof.

When the signature request using the identity certification ID from the ID acquisition unit244is received, the signature request unit282transmits the identity certification ID to the application information acquisition request unit284, and performs an acquisition request of the caller application information (process name). When the process name corresponding to the identity certification ID and the front display application information are acquired from the application information acquisition request unit284, the signature request unit282notifies the signature unit44of the external authenticator400of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit44, are received, the signature request unit282transmits the received information to the server verification cooperation unit242.

When the acquisition request of the caller application information (process name) with the identity certification ID is received from the signature request unit282, the application information acquisition request unit284notifies the ID verification unit266of the identity certification ID. When the process name corresponding to the notified identity certification ID and the front display application information are acquired from the ID verification unit266, the application information acquisition request unit284transmits the process name and the front display application information to the signature request unit282.

(Access Control to External Authenticator400in Authentication System10)

Access control to the external authenticator400in the authentication system10will be described below in detail with reference toFIG. 5toFIG. 8. Processing inFIG. 5toFIG. 8is processing executed in a timing before the terminal device100and the external authenticator400are coupled to each other (before (3) inFIG. 2).

FIG. 5illustrates a procedure (part1) of the access control processing.

In the processing illustrated inFIG. 5, first, the ID acquisition unit244of the Polyfill24executes a request to issue the identity certification ID to the ID issuing unit262of the Platform application26(SW). At this time, the ID issuing unit262acquires the process ID of the caller application (browser20). In a case of acquiring the process ID, when the Platform application25establishes inter-process communication with the Polyfill24by socket communication using Winsock, the ID issuing unit262acquires a port number and address information of the Platform application26side (server side of inter-process communication) illustrated inFIG. 9A. The ID issuing unit262acquires a port number and address information of the Polyfill24side (client side of inter-process communication) illustrated inFIG. 9B. The process ID is acquired by referring to TCP coupling list information illustrated inFIG. 9C.

The TCP coupling list information inFIG. 9Cincludes the number of TCP couplings of the Platform application26, the port number and address information of the server and the port number and address information of the client of the inter-process communication, and the process ID of the coupling source application. In the example illustrated inFIG. 9C, although not illustrated, it is assumed that 69 combinations of the port number and address information of the server and the port number and address information of the client of the inter-process communication, and the process ID of the coupling source application are stored.

The ID issuing unit262acquires the process ID of the TCP coupling including the information acquired inFIG. 9AandFIG. 9Bfrom the TCP coupling list information. In the example illustrated inFIG. 9AtoFIG. 9C, the ID issuing unit262may acquire the process ID=13332 of the coupling source application (browser20).

Next, the ID issuing unit262transmits an acquisition request of the caller application information together with the acquired process ID to the application information acquisition unit264(S12).

Next, the application information acquisition unit264acquires the caller application information (process name) corresponding to the received process ID by using the OS API (S14, S16). In this case, the application information acquisition unit264acquires a process name (for example, chrome.exe) corresponding to the process ID by using, for example, a process information acquisition API (PSAPI) of Windows (registered trademark).

Next, the application information acquisition unit264returns the acquired caller application information (process name) to the ID issuing unit262(S18). The ID issuing unit262generates the identity certification ID from the caller application information (process name) (S20). Specifically, for example, the ID issuing unit262generates a unique identity certification ID by using the acquired process name and a random number generation function. The ID issuing unit262manages the identity certification ID, the process ID, and the process name in the management information table80illustrated inFIG. 10Ain a linked manner. In the management information table80illustrated inFIG. 10A, the identity certification ID, the process ID, and the process name are managed in association with one another. In the example illustrated inFIG. 10A, the identity certification ID “12345”, the process ID “13332”, and the process name “chrome.exe” are associated with one another.

Thereafter, the ID issuing unit262returns the generated identity certification ID to the ID acquisition unit244of the Polyfill24(S22). After the processing inFIG. 5is performed, the process proceeds to processing illustrated inFIG. 6.

FIG. 6illustrates a procedure (part2) of the access control processing.

As described above, when the ID acquisition unit244of the Polyfill24receives the identity certification ID from the ID issuing unit262(S22inFIG. 5), the ID acquisition unit244transmits the identity certification ID (=12345) to the signature request unit282of the bridge interface28. With this, the ID acquisition unit244performs a signature request of the caller application (S30).

Next, the signature request unit282transmits the identity certification ID (=12345) to the application information acquisition request unit284to perform the acquisition request of the caller application information (S32). The application information acquisition request unit284transmits the identity certification ID (=12345) to the ID verification unit266of the Platform application26to perform the acquisition request of the caller application information (S34).

When acquiring the identity certification ID (=12345), the ID verification unit266identifies the caller application information (S36). At this time, the ID verification unit266verifies whether or not the identity certification ID (=12345) is the ID issued by itself by using the management information table80illustrated inFIG. 10A. When it may be confirmed that the received identity certification ID is present in the management information table80, the ID verification unit266acquires information of the process name (chrome.exe) corresponding to the identity certification ID and a window (application) arranged at the forefront surface in the Windows desktop environment. Hereinafter, information of an application arranged at the forefront surface is referred to as “front display application information”. When the front display application information is acquired, the ID verification unit266acquires a unique identifier (window handle) when the window is switched in the Windows desktop environment, and acquires the application name of the forefront surface based on the window handle. It is assumed that “chrome.exe” is acquired as the front display application information. When the process name and the front display application information are acquired, the ID verification unit266returns the process name and the front display application information to the application information acquisition request unit284of the bridge interface28(S38).

When the process name and the front display application information are received, the application information acquisition request unit284transmits the process name and the front display application information to the signature request unit282(S40).

Next, the signature request unit282is coupled to the external authenticator400which is coupled through the BLE, for example, by the CTAP communication of the FIDO, transmits the process name and the front display application information to the signature unit44of the external authenticator400, and executes the signature request (S42). At this time, the signature unit44executes the signature for the process name (chrome.exe) and the front display application information (chrome.exe) by using the private key managed by the key management unit42, and returns the process name with the signature and the front display application information with the signature to the signature request unit282(S44).

When the process name with the signature and the front display application information with the signature are received, the signature request unit282transmits the received information to the server verification cooperation unit242of the Polyfill24(S46). When the processing illustrated inFIG. 6is completed as described above, the process proceeds to processing illustrated inFIG. 7.

FIG. 7illustrates a procedure (part3) of the access control processing.

In the processing illustrated inFIG. 7, the server verification cooperation unit242of the Polyfill24transmits the process name with the signature and the front display application information with the signature received from the signature request unit282to the verification unit60of the authentication server300(S50).

When the process name with the signature and the front display application information with the signature are received, the verification unit60executes the verification processing (S52). In the verification processing, the verification unit60executes processing in accordance with the flowchart ofFIG. 8.

In the processing inFIG. 8, first, in step S60, the verification unit60executes signature verification of the process name (chrome.exe) and signature verification of the front display application information (chrome.exe) by using the public key.

Next, in step S62, it is determined whether or not the verification unit60succeeds in the verification. When the determination in step S62is affirmed, the process proceeds to step S64.

When proceeding to step S64, the verification unit60executes the white list verification and matching verification of the process name and the front display application information. In the white list verification, the verification unit60refers to a white list82(FIG. 10B) to verify whether or not the process name (chrome.exe) is included in the white list82. The white list82is a list in which a name (application name) of an application (browser) permitted to be coupled to the external authenticator400is registered in advance. In the matching verification, the verification unit60verifies whether or not the process name (chrome.exe) and the front display application name (chrome.exe) are identical to each other. The information used by the verification unit60in the verification is not limited to the process name. For example, the verification unit60may manage a version of the browser, a tab name of the browser, or the like, in the white list, and verify whether or not the version of the currently displayed browser or the tab name of the browser is included in the white list. By doing so, it is possible to further enhance accuracy of the verification.

Next, in step S66, it is determined whether or not the verification unit60succeeds in the verification. In step S66, when both the white list verification and the matching verification are successful, the determination is affirmed. When the determination in step S66is affirmed, the verification unit60proceeds to step S68.

When proceeding to step S68, the verification unit60sets the verification result to an access permission to the external authenticator400.

On the other hand, in a case where the determination in step S62or step S66is denied, the process proceeds to step S70. In step S70, the verification unit60sets the verification result to an access rejection to the external authenticator400.

After the processing in step S68or step S70is performed, the entire processing inFIG. 8is completed.

Returning toFIG. 7, when the verification processing (S52) is completed as described above, the verification unit60transmits the verification result to the server verification cooperation unit242(S54). For example, when the server verification cooperation unit242receives the verification result (access permission), the access to the external authenticator400from the browser20is permitted by the bridge interface28. On the other hand, when the server verification cooperation unit242receives the verification result (access rejection), the access to the external authenticator400from the browser20is rejected by the bridge interface28. In this way, in the embodiment, the bridge interface28functions as a control unit that controls coupling propriety between the browser20and the external authenticator400.

Each part illustrated in the drawings in the embodiment may not be required to be physically configured as illustrated in the drawings. That is, for example, specific forms of dispersion and integration of the parts are not limited to those illustrated in the drawings, and all or part thereof may be configured by being functionally or physically dispersed or integrated in given units according to various loads, the state of use, and the like. For example, the server verification cooperation unit242and the ID acquisition unit244may be integrated, or the ID issuing unit262, the application information acquisition unit264, and the ID verification unit266may be integrated. The order of processing illustrated in the drawings is not limited to the order described above, and the processing may be simultaneously performed or the order may be switched within the range in which the processing contents do not contradict one another.

All or any of the various processing functions performed in the devices may be performed on a central processing unit (CPU) (or a microcomputer, such as a microprocessor unit (MPU) or a micro controller unit (MCU)). Needless to say, all or given some of the various processing functions may be executed with a program analyzed and executed by a CPU (or a microcomputer such as an MPU or an MCU) or with hardware using wired logic.

Various processes described in the embodiments may be implemented by executing programs prepared in advance by a computer. In the following, an example of a computer that executes a program having the same function as in the embodiment is described.FIG. 11is a diagram illustrating the example of a computer500that executes an information processing program.

As illustrated inFIG. 11, the computer500includes a CPU190that executes various kinds of arithmetic processing, an input device195that receives data input, and a monitor193. The computer500includes a portable storage medium drive199for reading a program or the like from a portable storage medium, and a communication device197for wired or wireless coupling to other information processing apparatuses or the like. The computer500includes a read-only memory (ROM)192, a random-access memory (RAM)194, and a hard disk drive (HDD)196. Each of these devices included in the computer500is coupled to a bus198.

The ROM192stores an information processing program having the same function as that of each part of the terminal device100illustrated inFIG. 4. The ROM192stores the management information table80and various data for implementing the information processing program. The input device195receives, for example, input of various kinds of information such as operational information from a user of the computer500. The monitor193displays, for example, various screens such as a display screen for the user of the computer500. The communication device197is coupled to, for example, the network N and exchanges various kinds of information with the providing server200, the authentication server300, and other information processing apparatuses. The communication device197is coupled to the external authenticator400.

The CPU190reads the programs stored in the ROM192, loads the programs to the RAM194, and executes the programs to perform various kinds of processing. These programs may cause the computer500to function as each part of the terminal device100illustrated inFIG. 4.

The information processing program described above is not required to be stored in the ROM192. For example, the computer500may read and execute the program stored in a portable storage medium191that is readable by the computer500. Examples of the portable storage medium include a compact disc (CD)-ROM, a digital versatile disc (DVD), a USB memory, and the like. This information processing program may be stored in devices coupled to a public network, the Internet, a LAN, and the like, and the computer500may read and execute the information processing program therefrom.

As described in detail above, according to the embodiment, when the browser20coupled to the external authenticator400via the bridge interface, the ID issuing unit262acquires the information (process ID and process name) of the browser20. The ID issuing unit262generates the identity certification ID from the acquired process name, transmits the generated identity certification ID to the ID acquisition unit244, and manages the generated identity certification ID and the process ID and the process name of the browser20in the management information table80in association with one another. When the identity certification ID is acquired from the browser20via the bridge interface28, the ID verification unit266refers to the management information table80to acquire the process name corresponding to the identity certification ID and the front display application information. The signature request unit282transmits the process ID and the front display application information acquired by the ID verification unit266to the external authenticator400to make the signature request. The server verification cooperation unit242acquires, via the bridge interface28, the process name with the signature and the front display application information with the signature from the external authenticator400, and transmits the process name with the signature and the front display application information with the signature to the authentication server300. The bridge interface28controls coupling propriety between the browser20and the external authenticator400based on the authentication result by the authentication server300. That is, for example, in the embodiment, when a signature request is issued from the browser20that has received issue of the identity certification ID, a signature is performed on the process name of the browser and the front display application information by the external authenticator400. As a result of verifying the process name with the signature and the front display application information with the signature by the authentication server300, in a case where it is determined that the coupling may be permitted to be established, the access to the external authenticator400is permitted from the browser20. Accordingly, in the embodiment, a trust relationship is established at the location indicated by the double-headed arrow inFIG. 12A, and a trust relationship between the authentication library (Polyfill)24of the browser20and the external authenticator400is established, so that only the browser20authenticated by the authentication server300may access the external authenticator400. Therefore, it is possible to suppress an unauthorized application (an application such as a malware that operates in the background) installed in the terminal device100from accessing the external authenticator400. In this case, since PIN input is not required from the user, it is possible to suppress the decrease in the convenience of the user.

As a comparative example,FIG. 12Billustrates an example (FIDO UAF environment) in which an Authenticator Specific Module (ASM) controls coupling between an FIDO client and an authenticator. In this example, browser plug-in of the FIDO client measures a Facet ID and the ASM measures path information. The authenticator signs the Facet ID and the process ID, and the verification unit of the authentication server verifies the data with the signature. However, in a case where the CTAP communication is used for coupling to the external authenticator400as in the embodiment, the browser plug-in may not be used, so that the scheme illustrated inFIG. 12Bmay not be used. In contrast, by adopting the method as in the embodiment, even in the case where the terminal device100and the external authenticator400perform the CTAP communication, it is possible to limit the access from the unauthorized application.

In the above embodiment, the case where the ID verification unit266acquires the front display application information when acquiring the process name corresponding to the identity certification ID in step S36has been described, but the embodiment is not limited thereto. That is, for example, the ID verification unit266may acquire only the process name in step S36. In this case, in the signature unit44of the external authenticator400, a signature for the process name is executed, and in the authentication server300, the white list verification using the process name with the signature is performed. In a case where this white list verification is successful, the access from the browser20to the external authenticator400becomes possible. In this manner as well, the same action and effect as those of the above embodiment may be obtained.

In the above embodiment, the case where the external authenticator400is a smartphone has been described, but the embodiment is not limited thereto, and other Bluetooth devices, NFC mounted devices, USB tokens, and the like may also be used.

First Modification

FIG. 13illustrates a first modification of the authentication system. In Windows 8.1 or later, a Windows Biometric Framework (WBF) makes it possible to couple to a built-in authenticator. However, in a computer having a WBF non-compliant built-in authenticator, the built-in authenticator is required to be coupled through the bridge interface.FIG. 13illustrates a terminal device600having a built-in authenticator800to be coupled by such a bridge interface (28). In the terminal device600as described above as well, the Polyfill24, the Platform application26, the bridge interface28, and the signature unit44of the built-in authenticator800execute the same processing as that of the embodiment described above, thereby making it possible to suppress access to the built-in authenticator800from the unauthorized application. Since the processing of each part of the terminal device600is the same as that of the embodiment described above, description thereof will not be repeated.

Second Modification

FIG. 14illustrates a second modification of the authentication system. In an authentication system10′ according to the second modification, a measurement application26′ in a terminal device100′ as the information processing apparatus executes the verification of the caller application. In the second modification, as is clear from comparison betweenFIG. 14andFIG. 3, the bridge interface is omitted from the terminal device100′. The authentication server300of the second modification does not hold the white list. An external authenticator400′ of the second modification has functions of a CBOR parser unit340, a verification result acquisition unit342, and an access control unit344in addition to the functions of the external authenticator400ofFIG. 3.

An authentication library (Polyfill)24′ of the terminal device100′ of the second modification does not include the ID acquisition unit244included in the authentication library24of the above embodiment as illustrated inFIG. 15. The measurement application (Platform application)26′ of the terminal device100′ of the second modification has a function different from that of the Platform application26ofFIG. 3. Specifically, for example, as illustrated inFIG. 15, the Platform application26′ includes an application information acquisition unit360, an ID issuing unit362as a generation unit, a verification unit364, and an ID verification unit366. The Platform application26′ includes a white list382as a first list, a white list383as a second list, and a management information table380as a storage unit.

The white list382is a list similar to the white list82included in the authentication server300in the above embodiment. Specifically, for example, as illustrated inFIG. 16A, the white list382is a list in which a name (application name) of an application (browser) permitted to be coupled to the external authenticator400′ is registered in advance. As illustrated inFIG. 16B, the white list383is a list in which an address of a providing servers permitted to be coupled from the browser is registered in advance.

The management information table380is a table for storing the verification result of the verification unit364, and has a data structure as illustrated inFIG. 17. The management information table380will be described in detail later.

(Access Control to €External Authenticator400′ in Authentication System10′)

Next, access control to the external authenticator400′ in the authentication system10′ will be described in detail with reference toFIG. 18toFIG. 20.

FIG. 18illustrates a procedure (part1) of the access control processing. In the processing ofFIG. 18, first, when accessing the Platform application26′, the server verification cooperation unit242of the Polyfill24executes an issue request of the identity certification ID to the application information acquisition unit360(S71). In this case, the server verification cooperation unit242transmits, as the caller application information, information of challenge, origin, type, and process name to the application information acquisition unit360. Details of challenge, origin, and type are disclosed in “FIDO Alliance”, [Online], [searched on Nov. 22, 2018], Internet <https://fidoalliance.org/fido2/>, the challenge is a random value obtained from the authentication server. The origin is information represented by a scheme, a host, a port, or the like of a URL, and is, for example, “www.access-server1.co.jp:80” or the like. The type is a character string indicating registration or authentication, and is, for example, “webauthn.create” or “webauthn.get”. The process name is the process name of the caller application.

Next, the ID issuing unit362generates clientDataHash from the challenge, origin, and type acquired from the application information acquisition unit360, and uses the result as the identity certification ID (S72). In the second modification, instead of the identity certification ID (a unique ID generated by using the process name and the random number generation function) of the above embodiment, the clientDataHash obtainable by the API (WebAuthn API) specified in “WebAuthn spec” described in “FIDO Alliance”, [Online], [searched on Nov. 22, 2018], Internet <https://fidoalliance.org/fido2/> is assumed to be used as the identity certification ID. The clientDataHash may be generated from the challenge, origin, and type.

Next, the verification unit364acquires the caller application information from the ID issuing unit362(S73). The verification unit364verifies the caller application information by using the white lists382and383, and manages the identity certification ID (clientDataHash) in the management information table380. Specifically, for example, the verification unit364refers to the white list382to confirm whether or not the process name transmitted from the server verification cooperation unit242is present in the white list382. The verification unit364acquires information (front display application information) of the window (application) arranged at the forefront surface in the Windows desktop environment in the same manner as in the above embodiment, and confirms whether or not the information matches the process name transmitted from the server verification cooperation unit242. The verification unit364acquires address information of the providing server20from the origin, and confirms whether or not the address information is present in the white list383. The verification unit364stores each of the verification results (OK/NG), while linking with the identity certification ID (clientDataHash), in the management information table380. The verification unit364may request the address information of the providing server20from the server verification cooperation unit242without acquiring the address information of the providing server20from the origin.

As illustrated inFIG. 17, the management information table380stores “caller application verification result”, “process name and front display application information matching verification result”, and “providing server verification result” in association with “clientDataHash (identity certification ID)”. In the “caller application verification result”, “OK” is stored in a case where the received process name is present in the white list382, and “NG” is stored in a case of not being present. In the “process name and front display application information matching verification result”, “OK” is stored in a case where the received process name and the front display application information match each other, and “NG” is stored in a case of not matching. In the “providing server verification result”, “OK” is stored in a case where the address of the providing server is present in the white list383, and “NG” is stored in a case of not being present.

As described above, when the verification result of the verification unit364is stored in the management information table380, the verification unit364notifies the Polyfill24′ of the Relying Party application22of verification processing completion (S75).

FIG. 19illustrates a procedure (part2) of the access control processing. In the processing ofFIG. 19, as described above, when the Relying Party application22is notified of the verification processing completion notification of step S75, the Relying Party application22is coupled to the CTAP coupling interface40of the external authenticator400′ according to a coupling method by the API (WebAuthn API) specified by “WebAuthn spec” described in “FIDO Alliance”, [Online], [searched on Nov. 22, 2018], Internet <https://fidoalliance.org/fido2/>. At this time, the Relying Party application22transmits the challenge, origin, and type information to the external authenticator (S76).

The CBOR parser unit340of the external authenticator400′ parses and acquires the clientDataHash information from CBOR format data received by the CTAP coupling interface40(S77). The CBOR parser unit340transmits the clientDataHash to the ID verification unit366of the Platform application26′ via the verification result acquisition unit342(S78).

Next, the ID verification unit366of the Platform application26′ refers to the management information table380, and verifies whether or not there are data matching the clientDataHash received from the verification result acquisition unit342of the external authenticator400′ (S79). As a result of this verification, in a case where the matching clientDataHash is present in the management information table380, the verification result linked with the clientDataHash is acquired from the management information table380and returned to the verification result acquisition unit342of the external authenticator400′ (S80).

Next, when the verification result linked with the clientDataHash is acquired via the verification result acquisition unit342, the access control unit344of the external authenticator400′ performs the access control so as to permit the signature processing of the FIDO by the external authenticator400′ when all the acquired verification results are “OK”, and so as not to permit the signature processing when at least one is “NG” (S81). The access control unit344records the result of the access control in a log (FIG. 20) (S82). In the log inFIG. 20, three acquired verification results and permission/non-permission of the signature processing are recorded while being linked with a time stamp. The log may be referred to by an operator who maintains the external authenticator400′, for example.

As is apparent from the above description, in the second modification, the ID verification unit366has the functions as the acquisition unit that receives the clientDataHash generated by the external authenticator400′ and acquires the verification result linked with the clientDataHash from the management information table380, and as a transmission unit that transmits the acquisition result to the external authenticator400′.

As described above, according to the second modification, when the browser20is coupled to the external authenticator400′, the ID issuing unit362generates unique identification information (clientDataHash) by using the information (challenge, origin, type) acquired from the browser20by the application information acquisition unit360(S72). The verification unit364refers to the white list382to verify whether or not the clientDataHash is stored in the white list382, and stores the verification result in the management information table380while linking with the clientDataHash (S74). The verification unit364transmits the verification completion notification to the browser20(S75). The ID verification unit366receives the clientDataHash generated by the external authenticator400′ using the information (challenge, origin, type) acquired from the browser20(S78), acquires the verification result linked with the received clientDataHash from the management information table380, and transmits the verification result linked with the clientDataHash to the external authenticator400′ (S80). In this case, the access control unit344of the external authenticator400′ controls coupling propriety with the browser20based on the received verification result. In the second modification, this makes it possible to suppress the access to the external authenticator400′ from the unauthorized application within the terminal device100′. In the second modification, since the clientDataHash used in the FIDO authentication is used as the identity certification ID, difficulty in system development may be reduced as compared to a case where the identity certification ID that is not used in the FIDO authentication is used.

In the second modification, the verification unit364acquires information (front display application information) of the window (application) which is disposed at the forefront surface in the Windows desktop environment. The verification unit364confirms whether or not the acquired front display application information and the process name of the browser20match each other, and stores the confirmation result in the management information table380. In this case, in the external authenticator400′, in a case where the front display application information and the process name of the browser20do not match each other, by not permitting the coupling of the browser20, it is possible to suppress an unauthorized application (an application such as a malware that operates in the background) installed in the terminal device100′ from accessing the external authenticator400′.

In the second modification, the verification unit364refers to the white list383to verify whether or not the information of the providing server200coupled by the browser20is stored in the white list383, and stores the verification result in the management information table380. In this case, in the external authenticator400′, in a case where the information of the providing server200coupled by the browser20is not present in the white list383, by not permitting the coupling of the browser20, it is possible to suppress the access to the external authenticator400′ from an unauthorized providing server.

In the above embodiment, although the FIDO is cited as a technique in which the biometric information is collated on the side of the terminal device100to perform the user authentication processing, and the authentication result is transmitted to the authentication server300side, the technique is not limited thereto. For example, various techniques may be used as long as biometric authentication (local authentication) is performed in the external authenticator400coupled to the terminal device100. The local authentication means that the biometric data are held (registered) in the external authenticator used by the user, and authentication is performed in the external authenticator by using the held biometric data.

The above-described embodiment is a preferred embodiment. However, the embodiment is not limited to this embodiment, and may be variously modified within the subject matter of the embodiment.