Information processing device, information processing method, and information processing program

Abstract

To further improve the efficiency of authentication.SOLUTION: An information processing device includes: a registration processing unit that when receiving a registration request from an authenticator, stores in a key registry a public key for authentication common to a plurality of authentication servers that perform FIDO authentication; and an authentication processing unit that when receiving an authentication request from the authenticator, obtains the common public key for authentication from the key registry and performs FIDO authentication using the common public key for authentication.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing method, and an information processing program. [Background technology]

[0002] A technology relating to FIDO (Fast Identity Online) that uses an authentication device has been disclosed (see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2020-141331 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the above-mentioned conventional technologies still have room for improvement in terms of FIDO authentication, including identity verification during authentication.

[0005] The present application has been made in view of the above, and aims to further improve the efficiency of authentication. [Means for solving the problem]

[0006] The information processing device according to the present application includes: a registration processing unit that, upon receiving a registration request from an authenticator, stores an authentication public key common to a plurality of authentication servers that perform FIDO authentication in a key registry; and an authentication processing unit that, upon receiving an authentication request from the authenticator, acquires the common authentication public key from the key registry and performs FIDO authentication using the common authentication public key. When receiving a registration request from the authenticator, the registration processing unit stores an authentication public key common to multiple authentication servers belonging to the same authentication server group in the key registry on an authentication server group basis, and when receiving an authentication request from the authenticator, the authentication processing unit obtains an authentication public key common to multiple authentication servers belonging to the same authentication server group and performs FIDO authentication using the common authentication public key. It is characterized by: [Effects of the Invention]

[0007] According to one aspect of the embodiment, the efficiency of authentication can be further improved. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of FIDO authentication. [Figure 2] FIG. 2 is an explanatory diagram showing an overview of the information processing method according to the embodiment. [Figure 3] FIG. 3 is an explanatory diagram showing an overview of an information system and a trust relationship according to an embodiment. [Figure 4] Figure 4 is an explanatory diagram showing an overview of FIDO registration at RP1. [Figure 5] Figure 5 is an explanatory diagram showing an overview of the process of performing FIDO registration at RP1 and then performing FIDO registration at RP2. [Figure 6] Figure 6 is an explanatory diagram showing an overview of when FIDO registration is performed at RP1 and then FIDO authentication is performed at RP2. [Figure 7] Figure 7 is an explanatory diagram showing an overview of the case where FIDO registration is performed at RP1, and then ID federation is performed to register at RP2. [Figure 8] FIG. 8 is a diagram illustrating an example of the configuration of an information processing system according to the embodiment. [Figure 9] FIG. 9 is a diagram illustrating an example of the configuration of a terminal device according to the embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of a server device according to the embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of the user information database. [Figure 12] FIG. 12 is a diagram illustrating an example of the history information database. [Figure 13] FIG. 13 is a diagram illustrating an example of the key information database. [Figure 14] FIG. 14 is a flowchart showing a first processing procedure according to the embodiment. [Figure 15] FIG. 15 is a flowchart showing the second processing procedure according to the embodiment. [Figure 16]FIG. 16 is a flowchart showing the third processing procedure according to the embodiment. [Figure 17] FIG. 17 is a diagram illustrating an example of a hardware configuration. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an information processing device, an information processing method, and an information processing program according to the present application (hereinafter referred to as "embodiments") will be described in detail with reference to the drawings. Note that the information processing device, the information processing method, and the information processing program according to the present application are not limited to these embodiments. Furthermore, the same components in the following embodiments will be denoted by the same reference numerals, and duplicated descriptions will be omitted.

[0010] [1. Overview of information processing method] First, an overview of FIDO authentication will be described with reference to Figure 1. Figure 1 is an explanatory diagram showing an overview of FIDO authentication. Note that Figure 1 explains the basic mechanism of FIDO authentication.

[0011] 1, the information processing system 1 includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N (see FIG. 10) in a wired or wireless manner so as to be able to communicate with each other. In this embodiment, the terminal device 10 cooperates with the server device 100.

[0012] The terminal device 10 is a smart device such as a smartphone or tablet terminal used by a user U, and is a portable terminal device capable of communicating with any server device via a wireless communication network such as 4G (Generation (4G)) or LTE (Long Term Evolution) networks. The terminal device 10 has a screen such as a liquid crystal display with a touch panel function, and accepts various operations on displayed data such as content, such as tapping, sliding, and scrolling, performed by the user U with a finger or a stylus. An operation performed on an area of ​​the screen where content is displayed may be considered an operation on the content. The terminal device 10 may be not only a smart device, but also an information processing device such as a desktop PC (Personal Computer) or a notebook PC.

[0013] In this embodiment, the terminal device 10 functions as a FIDO client in FIDO authentication (Fast Identity Online). The FIDO client authenticates a user in cooperation with an authenticator. The authenticator may be implemented in the same device as the FIDO client (built-in authenticator), or may be implemented in a device physically different from the FIDO client (external authenticator).

[0014] For example, FIDO authentication can implement authentication methods using stored or possessed items such as PINs (Personal Identification Numbers), USB (Universal Serial Bus) security keys, and smart cards, as well as authentication methods using biometric or behavioral information such as fingerprints, faces, irises, veins, and voiceprints. Authentication methods are not limited to these, and any method can be implemented. Furthermore, multiple authentication methods can be combined to achieve multimodal biometric authentication or multifactor authentication.

[0015] For simplicity of explanation, the following description will be given assuming that the terminal device 10 is both a FIDO client and an authenticator, without distinguishing between the FIDO client and the authenticator. That is, the description will be given taking as an example a case where the authenticator is an internal authenticator. Note that, in reality, the authenticator may be an external authenticator that is physically independent from the terminal device 10 and can cooperate with the terminal device 10.

[0016] It is also possible to implement a Web authentication API (Application Programming Interface) that calls an authenticator from web content displayed in the FIDO client's web browser and enables FIDO authentication through interaction with the authentication server, but this description is omitted in this embodiment.

[0017] The server device 100 is an information processing device that functions as an authentication server (FIDO server) in FIDO authentication, and is realized by a computer, a cloud system, or the like. The authentication server corresponds to an RP (Relying Party) / IdP (Identity Provider). An RP (Relying Party) refers to an entity or organization that implements a FIDO server. In FIDO authentication, "secrets" such as passwords or biometric information are not shared between an authenticator and an authentication server, making it resistant to phishing.

[0018] As shown in Figure 1, in FIDO authentication, when an authentication server receives an authentication request from a user, it sends a challenge to the authenticator on the user side. The challenge is a random character string that is valid only once, and is a different data string each time determined based on random numbers. The user performs user verification using the authenticator and verifies their identity locally. The authenticator then signs the challenge with a private key as the verification result and sends the signed challenge as a signed response to the authentication server. When the authentication server receives the signed challenge, it verifies the signature with a public key. The pair of private and public keys is called a key pair.

[0019] In this way, with FIDO authentication, the authentication server uses a public key to verify that the authenticator on the user side has the appropriate private key, and the authenticator and authentication server do not share the "private key."

[0020] The server device 100 also functions as a federated RP / SP (Service Provider) that provides identity services through ID federation with RPs / IdPs that support FIDO authentication. When FIDO authentication and ID federation are combined, the authentication context is propagated from the authenticator to the federated RP / SP via the RP / IdP.

[0021] For simplicity of explanation, hereinafter, no distinction is made between the RP / IdP and the linked RP / SP, and the server device 100 is described as both the RP / IdP and the linked RP / SP. Note that in practice, the server device 100 as the RP / IdP and the server device 100 as the linked RP / SP may be different, physically independent server devices 100.

[0022] For example, the server device 100 may cooperate with the terminal device 10 of each user U and provide API (Application Programming Interface) services for various applications (hereinafter referred to as apps), etc., and various data to the terminal device 10 of each user U.

[0023] The server device 100 may also be an information processing device that provides some kind of online web service to the terminal device 10 of each user U. For example, the server device 100 may provide the following web services: internet connection, search service, social networking service (SNS), electronic commerce (EC), electronic payment, online games, online banking, online trading, hotel and ticket reservations, video and music distribution, news, maps, route search, route guidance, line information, operation information, and weather forecast. In practice, the server device 100 may cooperate with various servers that provide the above-mentioned web services and act as an intermediary for the web services or may be responsible for processing the web services.

[0024] The server device 100 can acquire user information about the user U. For example, the server device 100 acquires information about the attributes of the user U, such as the gender, age, and residential area of ​​the user U. The server device 100 then stores and manages the information about the attributes of the user U together with identification information (such as a user ID) that identifies the user U.

[0025] The server device 100 also acquires various types of history information (log data) indicating the behavior of the user U from the terminal device 10 of the user U or from various servers based on the user ID, etc. For example, the server device 100 acquires a location history, which is a history of the user U's location and date and time, from the terminal device 10. The server device 100 also acquires a search history, which is a history of search queries entered by the user U, from a search server (search engine). The server device 100 also acquires a browsing history, which is a history of content viewed by the user U, from a content server. The server device 100 also acquires a purchase history (payment history), which is a history of the user U's product purchases and payment processes, from an e-commerce server or a payment processing server. The server device 100 may also acquire a listing history and a sales history, which are a history of the user U's listings on the marketplace, from the e-commerce server or the payment processing server. The server device 100 also acquires a posting history, which is a history of the user U's posts, from a posting server or SNS server that provides a word-of-mouth posting service. The various servers and the like described above may be the server device 100 itself. That is, the server device 100 may function as the various servers and the like described above.

[0026] [1-1. Common public key (group key)] In conventional FIDO authentication, there is a one-to-one relationship between a key pair and an authentication server (FIDO server). When authenticating with an IdP (implementing FIDO server functionality) that supports FIDO authentication, it is necessary to register keys individually for each IdP, which is troublesome for users. In addition, the IdP must manage keys, which places a burden on the implementation and operation of management.

[0027] Therefore, this embodiment realizes a public key cryptography-based authentication system (FIDO multi-server credentials) that enables a common key pair to be used by multiple authentication servers. In this embodiment, an authenticator generates a FIDO key pair of a private key and a public key that can be used by multiple authentication servers in common, and the generated public key is managed in a key registry. Each of the multiple authentication servers manages a reference DID (Decentralized Identifier) ​​of the common public key and uses the common public key (group key) stored in the key registry. The reference DID of the public key is, for example, a public key URL (Uniform Resource Locator) that indicates the location of the public key.

[0028] FIG. 2 is an explanatory diagram showing an overview of an information processing method according to an embodiment. In this embodiment, there are a plurality of server devices 100, which are authentication servers. Each of the plurality of server devices 100 (100-i, i = 1 to n: n is arbitrary) belonging to the same authentication server group 100G (RP group) performs FIDO authentication using a public key common to the authentication servers in the authentication server group. Note that in practice, a public key common to all authentication servers may be used, rather than on an authentication server group basis.

[0029] 2, a user U holds accounts ID1 and ID2 in server device 100-1 (RP1) and server device 100-2 (RP2), respectively. That is, the user U holds account ID1 in server device 100-1 (RP1) and account ID2 in server device 100-2 (RP2).

[0030] Furthermore, the terminal device 10 (authentication device) has an authentication server group identification function and holds authentication server group information (group list). The authentication server group information includes, for example, the URLs of the server device 100-1 (RP1) and the server device 100-2 (RP2) that belong to the target authentication server group. In this way, the terminal device 10 manages the authentication server groups 100G (RP groups) and the key pairs (or private keys) for each group, and changes the private key used for FIDO authentication for each group.

[0031] Furthermore, the authentication server group 100G (RP group) includes a server device 100-1 (RP1) and a server device 100-2 (RP2). That is, RP1 and RP2 belong to the same authentication server group (RP group), and each has a user ID management function. RP1 manages user account ID1, and RP2 manages user account ID2. RP1 and RP2 also manage a reference DID of a common public key. The entity of the public key is stored in the key registry 200. In this embodiment, RP1 and RP2 each manage a key ID, a reference DID of the public key (public key URL), and a user ID (account) in association with each other.

[0032] The key registry 200 also stores a public key that can be shared by multiple authentication servers. The key registry 200 may be a storage server or the like on the network N (see FIG. 8), or may be one of multiple server devices 100 (RP) belonging to an authentication server group 100G (RP group). That is, the key registry 200 may be an independent database, or may be installed in one of the multiple server devices 100 (RP) in the group. The key registry 200 may also manage public keys in a blockchain using distributed ledger technology (DLT). For example, the key registry 200 may be a node that constitutes a blockchain network.

[0033] [1-2. System Overview] 3 is an explanatory diagram showing an overview of an information system and trust relationships according to an embodiment. For example, as shown in FIG. 3, there is trust established by user verification between a user U (user) and a terminal device 10 (authentication device). There is no trust established by user verification between other users and the terminal device 10 (authentication device).

[0034] Furthermore, cryptographically constructed trust exists between the terminal device 10 (authenticator) and each of the multiple server devices 100 (100-i, i = 1 to n: n is arbitrary) belonging to the authentication server group 100G. There is no cryptographically constructed trust between the terminal device 10 (authenticator) and a server device outside the group. Note that in the example of FIG. 3, there is cryptographically constructed trust with both the server device 100-1 (RP1) and the server device 100-2 (RP2) belonging to the authentication server group 100G (RP group).

[0035] Furthermore, there is trust established by FIDO authentication between user U and each of the multiple server devices 100 (100-i, i = 1 to n: n is arbitrary) belonging to the authentication server group 100G. There is no trust established by FIDO authentication between user U and a server device outside the group. Note that in the example of FIG. 3, there is trust established by FIDO authentication with both server device 100-1 (RP1) and server device 100-2 (RP2) belonging to the authentication server group 100G (RP group).

[0036] In this embodiment, a FIDO key that can be shared by multiple authentication servers is stored. In the example of Fig. 3, the key registry 200 stores a public key that can be shared by the server device 100-1 (RP1) and the server device 100-2 (RP2) that belong to the authentication server group 100G (RP group).

[0037] In this embodiment, there is a one-to-one relationship between a key pair and an authentication server group, but there is a one-to-many relationship between a key pair and an authentication server (FIDO server). Note that there is a one-to-many relationship between an authentication key pair and an authentication server, but there is a one-to-one relationship between a registration key pair and an authentication server. A registration key pair is, for example, a key pair for verifying the signature of an authenticator certificate (Attestation). An authentication key pair is, for example, a key pair for verifying the signature of a certificate (Assertion) of the user verification result in an authenticator. In other words, the registration key pair (attestation key pair) is the same as before.

[0038] However, technically, the relationship between the registration key pair and the authentication server can also be a one-to-many relationship, similar to the relationship between the authentication key pair and the authentication server. That is, in this embodiment, like the authentication public key, it is also possible to store a common registration public key that can be shared by multiple authentication servers in the key registry 200.

[0039] [1-3. FIDO registration at RP1] Fig. 4 is an explanatory diagram showing an overview of FIDO registration at RP 1. For example, as shown in Fig. 4, the terminal device 10 (authentication device) of a user U (user) transmits a registration request to a server device 100-1 (RP1) belonging to an authentication server group 100G (RP group) via a network N (see Fig. 10) in response to an operation or request from the user U (step S0).

[0040] Next, in response to a registration request from the terminal device 10 (authenticator) of the user U, the server device 100-1 (RP1) transmits a challenge and a group list to the terminal device 10 (authenticator) of the user U via the network N (see FIG. 10) along with a FIDO registration request for the authentication server group 100G (RP group) and the server device 100-1 (RP1) (step S1). The challenge is a random character string that is valid only once and is a different data string determined based on random numbers each time. The group list registers the server device 100-1 (RP1) and the server device 100-2 (RP2) that are the registration destinations. That is, the server device 100-1 (RP1) transmits, together with the challenge, a group list (RP-G list) for the server devices 100 (RP) that belong to the authentication server group 100G (RP group (RP-G)) that includes the server device 100-1 (RP1).

[0041] The user U performs user verification using the terminal device 10 (authentication device) and locally verifies the identity of the user (step S2). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

[0042] Next, if the user verification is successful, the terminal device 10 (authenticator) signs the challenge with the registration private key (attestation private key), generates an attestation document, and also verifies that the server devices 100 (RPs) in the group do not have a common authentication key pair (RP-G authentication key pair), and generates an authentication key pair (RP-G authentication key pair) (step S3). The terminal device 10 (authenticator) stores the authentication private key (RP-G authentication private key) common to the server devices 100 (RPs) in the group. Note that the terminal device 10 (authenticator) may store the common authentication private key (RP-G authentication private key) in association with the authentication server group (RP-G).

[0043] Next, the terminal device 10 (authentication device) sends a signed challenge (attestation document) signed with the registration private key (attestation private key) and an authentication public key (RP-G authentication public key) common to the server devices 100 (RP) in the group as a registration response to the server device 100-1 (RP1) that sent the FIDO registration request (step S4).

[0044] Next, upon receiving the signed challenge (attestation document), the server device 100-1 (RP1) verifies the signature using the registration public key (attestation public key) (step S5).

[0045] Next, if the signature verification is successful, the server device 100-1 (RP1) stores an authentication public key (RP-G authentication public key) common to the server devices 100 (RP) in the group in the key registry 200, and also associates and saves the user ID (ID1) of the user U with the authentication public key common to the server devices 100 (RP) in the group (step S6). In the example of FIG. 3, the server device 100-1 (RP1) manages a key ID for identifying the authentication public key common to the server devices 100 (RP) in the group, a reference DID (DID1) of the authentication public key common to the server devices 100 (RP) in the group, and the user ID (ID1) of the user U, by associating them with each other. The key registry 200 manages the authentication public key (RP-G authentication public key) by associating it with the reference DID (DID1) of the authentication public key (RP-G authentication public key).

[0046] As a result, authentication to an authentication server belonging to the authentication server group 100G (RP group) can be performed using the RP-G authentication public key.

[0047] [1-4. FIDO registration at RP2] Fig. 5 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP2 after FIDO registration is performed at RP1. For example, as shown in Fig. 5, the terminal device 10 (authentication device) of a user U (user) transmits a registration request to a server device 100-2 (RP2) belonging to an authentication server group 100G (RP group) via a network N (see Fig. 10) in response to an operation or request from the user U (step S10). This registration request is a registration request for a group key based on a group list.

[0048] Next, in response to a registration request from the terminal device 10 (authenticator) of the user U, the server device 100-2 (RP2) transmits a challenge to the terminal device 10 (authenticator) of the user U via the network N (see FIG. 10) along with a FIDO registration request to the authentication server group 100G (RP group) and the server device 100-2 (RP2) (step S11). At this time, along with the FIDO registration request, information indicating the server device 100-2 (RP2) as the registration destination and information indicating the authentication server group 100G (RP-G) are transmitted.

[0049] The user U performs user verification using the terminal device 10 (authentication device) and verifies the identity of the user locally (step S12). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

[0050] Next, if the user verification is successful, the terminal device 10 (authentication device) confirms that the server device 100-2 (RP2) belongs to the authentication server group 100G (RP group), signs the challenge with the registration private key (attestation private key), and generates an attestation document (step S13). At this time, although the server devices 100 (RP) in the group already have a common authentication private key (RP-G authentication private key), here the "attestation private key" is used in accordance with the original FIDO registration process.

[0051] Next, the terminal device 10 (authentication device) sends a signed challenge (attestation document) signed with the registration private key (attestation private key) and an authentication public key (RP-G authentication public key) common to the server devices 100 (RP) in the group as a registration response to the server device 100-2 (RP2) that sent the FIDO registration request (step S14).

[0052] Next, upon receiving the signed challenge (attestation document), the server device 100-2 (RP2) verifies the signature using the registration public key (attestation public key) (step S15).

[0053] Next, if the signature verification is successful, the server device 100-2 (RP2) recognizes that it is a group key registration and uses the key ID to obtain the reference DID (DID1) of the authentication public key (RP-G authentication public key) from the key registry 200 (step S16).

[0054] Note that server device 100-2 (RP2) belonging to authentication server group 100G (RP group) knows that the registration request in step S10 is a "group key registration request," and the response in step S14 inherits the challenge in step S10 and is associated with the registration request in step S10. Therefore, if the signature verification is successful, server device 100-2 (RP2) recognizes this as a legitimate group key registration in the processing of step S16 and proceeds with the processing.

[0055] Next, the server device 100-2 (RP2) acquires (or generates) a user ID (ID2) for the user U at RP2 and completes authentication (step S17). For example, if the user U is already registered for an existing service at RP2, the server device 100-2 (RP2) acquires the user ID (ID2) of the registered user U, and if the user U is an unregistered user, the server device 100-2 (RP2) generates (issues) a new user ID (ID2) for the new user U. At this time, the server device 100-2 (RP2) manages a key ID (keyID) for identifying an authentication public key common to the server devices 100 (RP) in the group, a reference DID (DID1) for the authentication public key common to the server devices 100 (RP) in the group, and the user ID (ID2) in association with each other.

[0056] [1-5. FIDO authentication with RP2] Fig. 6 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP 1 and then FIDO authentication is performed at RP 2. For example, as shown in Fig. 6, the terminal device 10 (authentication device) of a user U (user) transmits an authentication request to a server device 100-2 (RP2) belonging to an authentication server group 100G (RP group) via a network N (see Fig. 10) in response to an operation or request from the user U (step S20).

[0057] Next, in response to an authentication request from the terminal device 10 (authentication device) of the user U, the server device 100-2 (RP2) transmits a challenge to the terminal device 10 (authentication device) of the user U via the network N (see FIG. 10) along with a FIDO authentication request to the authentication server group 100G (RP group) and the server device 100-2 (RP2) (step S21). At this time, along with the FIDO authentication request, information indicating the server device 100-2 (RP2) that is the authentication destination and information indicating the authentication server group 100G (RP-G) are transmitted.

[0058] The user U performs user verification using the terminal device 10 (authentication device) and locally verifies the identity of the user (step S22). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

[0059] Next, if the user verification is successful, the terminal device 10 (authentication device) confirms that the server device 100-2 (RP2) belongs to the authentication server group 100G (RP group), signs the challenge with a common authentication private key (RP-G authentication private key), and generates an assertion document (step S23). Here, the terminal device 10 uses the existing RP-G authentication private key that was generated during FIDO registration with the server device 100-1 (RP1) shown in Figure 4.

[0060] Next, the terminal device 10 (authentication device) sends a signed challenge (assertion document) signed with the common authentication private key (RP-G authentication private key) as an authentication response to the server device 100-2 (RP2) that sent the FIDO authentication request (step S24).

[0061] Next, when the server device 100-2 (RP2) receives a signed challenge (assertion document) from the terminal device 10 (authenticator) of the user U via the network N (see Figure 10), it uses the key ID, but when it confirms that there is no public key URL because it is not registered, it uses the key ID to obtain the reference DID (DID1) of the authentication public key (RP-G authentication public key) and the authentication public key (RP-G authentication public key) from the key registry 200 (step S25).

[0062] As a method of confirming that "there is no public key URL," for example, when the server device 100-2 (RP2) receives a signed challenge (assertion document), it searches the key information database (key ID-public key URL-user ID) of its own authentication server group 100G (RP-G) using the key ID as a key to confirm the existence of a corresponding public key URL. Since it is assumed that this is the first time key registration is being performed for the server device 100-2 (RP2), the data is originally empty, and it is determined that there is no public key URL corresponding to the key ID (keyID).

[0063] Next, the server device 100-2 (RP2) verifies the signature of the signed challenge (assertion document) using the authentication public key (RP-G authentication public key) (step S26).

[0064] Next, if the signature verification is successful, the server device 100-2 (RP2) acquires (or generates) the user ID (ID2) of the user U at RP2 and completes the authentication (step S27). At this time, the server device 100-2 (RP2) manages a key ID (keyID) for identifying the authentication public key common to the server devices 100 (RP) in the group, a reference DID (DID1) of the authentication public key common to the server devices 100 (RP) in the group, and the user ID (ID2) in association with each other.

[0065] [1-6. Link your ID and register on RP2] 7 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP1, and then registration is performed at RP2 through ID federation. For example, as shown in Fig. 7, in response to an operation or request from user U, terminal device 10 (authentication device) of user U transmits a group key registration request to server device 100-2 (RP2) belonging to authentication server group 100G (RP group) via network N (see Fig. 10) (step S30).

[0066] Next, the server device 100-2 (RP2) determines that the terminal device 10 (authenticator) of the user U (user) has already been registered with the server device 100-1 (RP1), and in response to a group key registration request from the terminal device 10 (authenticator) of the user U, transmits a challenge from the server device 100-1 (RP1) to the terminal device 10 (authenticator) of the user U via the network N (see FIG. 10) along with a FIDO authentication request for the authentication server group 100G (RP group) and the server device 100-2 (RP2) (step S31). At this time, when the server device 100-2 (RP2) receives the group key registration request, it may determine that the terminal device 10 (authenticator) has already been registered with the server device 100-1 (RP1), and request authentication from the server device 100-1 (RP1). For example, when the server device 100-2 (RP2) receives a group key registration request from the terminal device 10 (authentication device) of the user U (user), the server device 100-2 (RP2) may redirect the request to the server device 100-1 (RP1) where the group key has already been registered.

[0067] The user U performs user verification using the terminal device 10 (authentication device) and locally verifies the identity of the user (step S32). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

[0068] Next, if the user verification is successful, the terminal device 10 (authentication device) confirms that the server devices 100 (RPs) in the group have a common authentication private key (RP-G authentication private key) and that the server device 100-2 (RP2) belongs to the authentication server group 100G (RP group), signs the challenge with the common authentication private key (RP-G authentication private key), and generates an assertion document (step S33). Here, ID federation is used instead of FIDO authentication as a method of notifying RP2 of the authentication information and DID information (it is assumed that ID1 and ID2 are federated between RP1 and RP2).

[0069] Next, the terminal device 10 (authentication device) sends a signed challenge (assertion document) signed with the common authentication private key (RP-G authentication private key) as an authentication response to the server device 100-1 (RP1) that sent the FIDO authentication request (step S34).

[0070] Next, upon receiving the signed challenge (assertion document), server device 100-1 (RP1) creates a group key registration authentication assertion (assertion document, including DID1) and transmits the group key registration authentication assertion (assertion document, including DID1) to user U's terminal device 10 (authenticator) via network N (see FIG. 10) (step S35). That is, the group key registration authentication assertion includes the signed challenge (assertion document) and the reference DID (DID1) of the authentication public key.

[0071] In this case, when the server device 100-1 (RP1) receives the signed challenge (assertion document), it may verify the signature of the signed challenge (assertion document) using the authentication public key (RP-G authentication public key), and if the signature verification is successful, it may create an authentication assertion for group key registration (assertion document, including DID1).

[0072] Next, the terminal device 10 (authentication device) of the user U transmits a group key registration authentication assertion (assertion document, including DID1) to the server device 100-2 (RP2) via the network N (see FIG. 10) (step S36).

[0073] Next, when the server device 100-2 (RP2) receives the group key registration authentication assertion (assertion document, including DID1) from the terminal device 10 (authenticator) of the user U via the network N (see Figure 10), it uses the key ID, but when it confirms that there is no public key URL because it is not registered, it uses the reference DID (DID1) of the authentication public key included in the group key registration authentication assertion to obtain the authentication public key (RP-G authentication public key) from the key registry 200 (step S37).

[0074] Next, the server device 100-2 (RP2) obtains (extracts) the signed challenge (assertion document) included in the group key registration authentication assertion and verifies the signature of the signed challenge (assertion document) using the authentication public key (RP-G authentication public key) (step S38).

[0075] Next, if the signature verification is successful, the server device 100-2 (RP2) acquires (or generates) the user ID (ID2) of the user U at RP2 and completes the authentication (step S39). At this time, the server device 100-2 (RP2) manages a key ID (keyID) for identifying the authentication public key common to the server devices 100 (RP) in the group, a reference DID (DID1) of the authentication public key common to the server devices 100 (RP) in the group, and the user ID (ID2) in association with each other.

[0076] [1-7. Updating / deleting group keys, updating group lists] In the above example, only the process for registering a common public key (group key) was described, but the same process as for registering the group key can also be used for updating the group key, deleting the group key, and updating the group list.

[0077] [1-8. Effects] In this embodiment, for FIDO key registration, if the authentication server group 100G is the same, a single key can be registered for multiple authentication servers, and the user's terminal device (authentication device) does not need to have a private key for each authentication server. This simplifies FIDO key management.

[0078] For different authentication server groups 100G, the user's terminal device (authentication device) manages the authentication server groups 100G and changes the private key used for FIDO authentication for each authentication server group 100G.

[0079] Furthermore, the authentication server simplifies identity management and reduces management costs because public key management is no longer required.

[0080] [2. Example of information processing system configuration] Next, a configuration of an information processing system 1 including a server device 100 according to an embodiment will be described with reference to Fig. 8. Fig. 8 is a diagram showing an example of the configuration of the information processing system 1 according to an embodiment. As shown in Fig. 8, the information processing system 1 according to an embodiment includes a terminal device 10 and a server device 100. These various devices are connected to each other via a network N so as to be able to communicate with each other via a wired or wireless connection. The network N is, for example, a LAN (Local Area Network) or a WAN (Wide Area Network) such as the Internet.

[0081] Furthermore, the number of devices included in the information processing system 1 shown in Fig. 8 is not limited to that shown in the figure. For example, in Fig. 8, for the sake of simplicity, only one terminal device 10 is shown, but this is merely an example and is not limiting, and two or more devices may be included.

[0082] The terminal device 10 is an information processing device used by a user U. For example, the terminal device 10 may be a smart device such as a smartphone or tablet terminal, a mobile phone such as a feature phone (Gala-ke or Gala-ho), a PC (Personal Computer), a PDA (Personal Digital Assistant), a game console or AV device with communication functions, an information appliance or digital appliance, a car navigation system, a wearable device such as a smart watch or a head-mounted display, smart glasses, etc. The terminal device 10 may also be a house or building, a car, a home appliance, an electronic device, etc. that is compatible with the Internet of Things (IOT).

[0083] In addition, the terminal device 10 can connect to the network N via a wireless communication network such as LTE (Long Term Evolution), 4G (4th Generation), or 5G (5th Generation: 5th generation mobile communication system), or via short-range wireless communication such as Bluetooth (registered trademark) or wireless LAN (Local Area Network), and communicate with the server device 100.

[0084] The server device 100 is, for example, a computer such as a PC or a blade server, or a mainframe or a workstation, etc. The server device 100 may be realized by cloud computing.

[0085] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be described with reference to Fig. 9. Fig. 9 is a diagram showing an example of the configuration of the terminal device 10. As shown in Fig. 9, the terminal device 10 includes a communication unit 11, a display unit 12, an input unit 13, a positioning unit 14, a sensor unit 20, a control unit 30 (controller), and a storage unit 40.

[0086] (Communications Department 11) The communication unit 11 is connected to a network N (see FIG. 8) by wire or wirelessly, and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 is realized by a NIC (Network Interface Card), an antenna, etc.

[0087] (Display section 12) Display unit 12 is a display device that displays various information such as position information. For example, display unit 12 is a liquid crystal display (LCD) or an organic electro-luminescent display (OLED). Display unit 12 is also a touch panel display, but is not limited to this.

[0088] (Input section 13) The input unit 13 is an input device that accepts various operations from the user U. For example, the input unit 13 has buttons for inputting characters, numbers, and the like. The input unit 13 may be an input / output port (I / O port), a USB (Universal Serial Bus) port, or the like. If the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. The input unit 13 may be a microphone that accepts voice input from the user U. The microphone may be wireless.

[0089] (Positioning unit 14) The positioning unit 14 receives signals (radio waves) transmitted from satellites of a GPS (Global Positioning System), and acquires position information (e.g., latitude and longitude) indicating the current position of the terminal device 10, which is the device itself, based on the received signals. That is, the positioning unit 14 positions the position of the terminal device 10. Note that GPS is merely an example of a GNSS (Global Navigation Satellite System).

[0090] The positioning unit 14 can also measure the position using various methods other than GPS. For example, the positioning unit 14 may measure the position by using various communication functions of the terminal device 10 as an auxiliary positioning means for position correction, etc., as described below.

[0091] (Wi-Fi positioning) For example, the positioning unit 14 uses a Wi-Fi (registered trademark) communication function of the terminal device 10 or a communication network provided by each communication company to measure the position of the terminal device 10. Specifically, the positioning unit 14 performs Wi-Fi communication or the like and measures the distance to a nearby base station or access point, thereby measuring the position of the terminal device 10.

[0092] (Beacon positioning) The positioning unit 14 may also measure the position by using a Bluetooth (registered trademark) function of the terminal device 10. For example, the positioning unit 14 measures the position of the terminal device 10 by connecting to a beacon transmitter connected by the Bluetooth (registered trademark) function.

[0093] (geomagnetic positioning) The positioning unit 14 also measures the position of the terminal device 10 based on a geomagnetic pattern of a structure that has been measured in advance and a geomagnetic sensor that the terminal device 10 has.

[0094] (RFID positioning) Furthermore, for example, if the terminal device 10 has a function of an RFID (Radio Frequency Identification) tag equivalent to a contactless IC card used at station ticket gates, in stores, etc., or has a function of reading an RFID tag, the location of use is recorded together with information on payment, etc., made by the terminal device 10. The positioning unit 14 may obtain such information to determine the location of the terminal device 10. Alternatively, the location may be determined by an optical sensor, an infrared sensor, or the like provided in the terminal device 10.

[0095] The positioning unit 14 may measure the position of the terminal device 10 using one or a combination of the above-mentioned positioning means, as needed.

[0096] (Sensor unit 20) The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. The connection may be wired or wireless. For example, the sensors may be detection devices other than the terminal device 10, such as wearable devices or wireless devices. In the example shown in FIG. 9, the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, a barometric pressure sensor 23, a temperature sensor 24, a sound sensor 25, a light sensor 26, a magnetic sensor 27, and an image sensor (camera) 28.

[0097] The above-described sensors 21 to 28 are merely examples and are not intended to be limiting. That is, the sensor unit 20 may be configured to include some of the sensors 21 to 28, or may include other sensors such as a humidity sensor in addition to or instead of the sensors 21 to 28.

[0098] The acceleration sensor 21 is, for example, a three-axis acceleration sensor, and detects physical movements of the terminal device 10, such as the direction of movement, speed, and acceleration of the terminal device 10. The gyro sensor 22 detects physical movements of the terminal device 10, such as tilt in three axial directions, based on the angular velocity of the terminal device 10. The air pressure sensor 23 detects, for example, the air pressure around the terminal device 10.

[0099] Since the terminal device 10 includes the acceleration sensor 21, the gyro sensor 22, the atmospheric pressure sensor 23, etc., it is possible to measure the position of the terminal device 10 using a technique such as Pedestrian Dead-Reckoning (PDR) that uses these sensors 21 to 23. This makes it possible to obtain indoor position information that is difficult to obtain using a positioning system such as GPS.

[0100] For example, the number of steps, walking speed, and distance walked can be calculated using a pedometer that uses the acceleration sensor 21. In addition, the direction of travel, line of sight, and body tilt of the user U can be determined using the gyro sensor 22. In addition, the altitude and floor on which the terminal device 10 of the user U is located can be determined from the air pressure detected by the air pressure sensor 23.

[0101] The temperature sensor 24 detects, for example, the temperature around the terminal device 10. The sound sensor 25 detects, for example, the sound around the terminal device 10. The light sensor 26 detects the illuminance around the terminal device 10. The magnetic sensor 27 detects, for example, the geomagnetism around the terminal device 10. The image sensor 28 captures an image around the terminal device 10.

[0102] The above-mentioned air pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the air pressure, temperature, sound, and illuminance, respectively, and capture images of the surroundings, thereby detecting the environment and situation around the terminal device 10. Furthermore, the accuracy of the location information of the terminal device 10 can be improved based on the environment and situation around the terminal device 10.

[0103] (control unit 30) The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit), ROM (Read Only Memory), RAM, input / output ports, etc., and various other circuits. The control unit 30 may also be configured with hardware such as an integrated circuit, for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). The control unit 30 includes a transmitting unit 31, a receiving unit 32, and a processing unit 33.

[0104] (Transmitter 31) The transmission unit 31 can transmit, for example, various information input by the user U using the input unit 13, various information detected by each sensor 21 to 28 mounted on or connected to the terminal device 10, and location information of the terminal device 10 measured by the positioning unit 14 to the server device 100 via the communication unit 11.

[0105] (Receiving unit 32) The receiving unit 32 can receive various types of information provided by the server device 100 and requests for various types of information from the server device 100 via the communication unit 11.

[0106] (Processing unit 33) The processing unit 33 controls the entire terminal device 10, including the display unit 12. For example, the processing unit 33 can output various information transmitted by the transmitting unit 31 and various information received from the server device 100 by the receiving unit 32 to the display unit 12 for display.

[0107] Furthermore, the processing unit 33 has a group management unit 33A, a verification unit 33B, a confirmation unit 33C, and a key generation unit 33D. In practice, the processing unit 33 may function as the group management unit 33A, the verification unit 33B, the confirmation unit 33C, and the key generation unit 33D described below by starting an app or executing a program.

[0108] (Group Management Department 33A) The group management unit 33A manages multiple authentication servers (server devices 100) that perform FIDO authentication in units of authentication server groups. At this time, the transmission unit 31 transmits a registration request to one of the multiple authentication servers (server devices 100) that belong to the same authentication server group. The reception unit 32 receives a challenge in response to the registration request. Furthermore, the transmission unit 31 transmits an authentication request to one of the multiple authentication servers (server devices 100) that belong to the same authentication server group. The reception unit 32 receives a challenge in response to the authentication request. Alternatively, the transmission unit 31 transmits a key registration request to a second authentication server among the multiple authentication servers (server devices 100) that belong to the same authentication server group, where the user is not registered. The reception unit 32 receives a first challenge from a first authentication server among the multiple authentication servers (server devices 100), where the user has been registered.

[0109] (Verification section 33B) When the verification unit 33B receives a challenge for a registration request, if the user verification is successful, the verification unit 33B creates a signed challenge by signing the challenge using the registration private key. Also, when the verification unit 33B receives a challenge for an authentication request, if the user verification is successful, the verification unit 33B creates a signed challenge by signing the challenge using the common authentication private key.

[0110] If the user verification is successful, the verification unit 33B creates a first signed challenge by signing the first challenge using the common authentication private key. At this time, the transmission unit 31 transmits the first signed challenge to the first authentication server. The reception unit 32 receives the second challenge and a group key registration authentication assertion including the reference DID of the public key from the first authentication server.

[0111] If the user verification is successful, the verification unit 33B creates a second signed challenge by signing the second challenge using the common authentication private key. At this time, the transmission unit 31 transmits the second signed challenge and a group key registration authentication assertion including the reference DID of the public key to the second authentication server.

[0112] (Confirmation part 33C) The confirmation unit 33C confirms whether or not there is a common authentication key pair among the multiple authentication servers (server devices 100) belonging to the authentication server group. At this time, if there is a common authentication key pair, the transmission unit 31 transmits a signed challenge.

[0113] (Key generation unit 33D) If there is no common authentication key pair, the key generation unit 33D generates a key pair of an authentication private key and an authentication public key that are common to the multiple authentication servers (server devices 100) belonging to the authentication server group. At this time, if there is no common authentication key pair, the transmission unit 31 transmits the common authentication public key together with the signed challenge.

[0114] (Storage unit 40) The storage unit 40 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical disk, etc. The storage unit 40 stores various programs, various data, etc.

[0115] Furthermore, a group list 40A, a registration private key 40B, and an authentication private key 40C are stored in a secure area (secure element) of the storage unit 40. In this case, the group list 40A, the registration private key 40B, and the authentication private key 40C may each be stored in a different secure area. In practice, the group list 40A, the registration private key 40B, and the authentication private key 40C may be stored in a linked manner, or the registration private key 40B and the authentication private key 40C may be included in the group list 40A. Furthermore, only the registration private key 40B and the authentication private key 40C may be stored in the secure area. In other words, the group list 40A may be stored in a normal area.

[0116] The group list 40A is data that registers, for each authentication server group, a plurality of server devices 100 (RPs) that belong to the same authentication server group 100G (RP group). For example, the group list 40A is data in a list format that registers the URLs of the server devices 100 in the group. Note that the data format is not limited to a list format, and may also be a table format. In other words, any data format may be used as long as it can fulfill the role of the group list 40A.

[0117] Registration private key 40B is a registration private key (attestation private key) of a conventional registration key pair. However, in reality, registration private key 40B may also be a registration private key of a registration key pair common to authentication servers in the same authentication server group, similar to authentication private key 40C.

[0118] The authentication private key 40C is an authentication private key of an authentication key pair common to the authentication servers in the same authentication server group, on an authentication server group basis. That is, the authentication private key 40C is an authentication private key (RP-G authentication private key) common to the server devices 100 (RP) in the group.

[0119] [4. Server device configuration example] Next, the configuration of the server device 100 according to the embodiment will be described with reference to Fig. 10. Fig. 10 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Fig. 10, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

[0120] (Communication unit 110) The communication unit 110 is realized by, for example, a network interface card (NIC), etc. The communication unit 110 is also connected to a network N (see FIG. 8) by wire or wirelessly.

[0121] (Storage unit 120) The storage unit 120 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD, an SSD, an optical disk, etc. As shown in Fig. 10, the storage unit 120 has a user information database 121, a history information database 122, and a key information database 123.

[0122] (User Information Database 121) The user information database 121 stores user information about the user U. For example, the user information database 121 stores various information such as the attributes of the user U. FIG. 11 is a diagram showing an example of the user information database 121. In the example shown in FIG. 11, the user information database 121 has items such as "User ID (Identifier)," "Age," "Gender," "Home," "Workplace," and "Interests."

[0123] The "user ID" indicates identification information for identifying the user U. The "user ID" may be the contact information of the user U (telephone number, email address, etc.), or may be identification information for identifying the terminal device 10 of the user U.

[0124] Furthermore, "age" indicates the age of user U identified by the user ID. Note that "age" may be information indicating the specific age of user U (e.g., 35 years old), or may be information indicating the generation of user U (e.g., 30s). Alternatively, "age" may be information indicating the date of birth of user U, or may be information indicating the generation of user U (e.g., born in the 1980s). Furthermore, "gender" indicates the gender of user U identified by the user ID.

[0125] Furthermore, "home" indicates the location information of the home of user U identified by the user ID. In the example shown in FIG. 11, "home" is illustrated as an abstract code such as "LC11," but it may also be latitude and longitude information, etc. Furthermore, for example, "home" may also be the name of an area or an address.

[0126] Furthermore, "workplace" indicates location information of the workplace (school in the case of a student) of user U identified by the user ID. In the example shown in FIG. 11, "workplace" is illustrated as an abstract code such as "LC12," but it may also be latitude and longitude information, etc. Furthermore, for example, "workplace" may also be the name of a region or an address.

[0127] Furthermore, "interests" indicate the interests of user U identified by the user ID. In other words, "interests" indicate subjects in which user U identified by the user ID is highly interested. For example, "interests" may be search queries (keywords) entered by user U into a search engine. In the example shown in FIG. 11, each user U is shown with one "interest," but there may be multiple "interests."

[0128] For example, in the example shown in FIG. 11, the age of user U identified by user ID "U1" is "20s" and the gender is "male." Furthermore, for example, the home address of user U identified by user ID "U1" is "LC11." Furthermore, for example, the workplace of user U identified by user ID "U1" is "LC12." Furthermore, for example, the user U identified by user ID "U1" is interested in "sports."

[0129] 11, abstract values ​​such as "U1", "LC11", and "LC12" are used for illustration, but "U1", "LC11", and "LC12" are assumed to store information such as specific character strings and numerical values. Below, abstract values ​​may also be illustrated in diagrams relating to other information.

[0130] The user information database 121 may store various types of information depending on the purpose, without being limited to the above. For example, the user information database 121 may store various types of information related to the terminal device 10 of the user U. The user information database 121 may also store information related to the user U's attributes, such as demographic attributes, psychographic attributes, geographic attributes, and behavioral attributes. For example, the user information database 121 may store information such as name, family structure, hometown (hometown), occupation, job title, income, qualifications, type of residence (detached house, apartment, etc.), whether or not the user has a car, commuting time, commuting route, commuter pass area (station, line, etc.), frequently used stations (other than the station nearest to home or workplace), extracurricular activities (location, time zone, etc.), hobbies, interests, lifestyle, etc.

[0131] (History Information Database 122) The history information database 122 stores various information related to history information (log data) that indicates the behavior of the user U. Fig. 12 is a diagram showing an example of the history information database 122. In the example shown in Fig. 12, the history information database 122 has items such as "user ID," "location history," "search history," "browsing history," "purchase history," and "posting history."

[0132] "User ID" indicates identification information for identifying user U. "Location history" indicates the location history, which is the history of user U's location and movements. "Search history" indicates the search history, which is the history of search queries entered by user U. "Browsing history" indicates the browsing history, which is the history of content viewed by user U. "Purchase history" indicates the purchase history, which is the history of purchases made by user U. "Posting history" indicates the posting history, which is the history of posts made by user U. "Posting history" may also include questions about user U's possessions.

[0133] For example, in the example shown in Figure 12, user U, identified by user ID "U1," moved as shown in "Location History #1," searched as shown in "Search History #1," viewed content as shown in "Viewing History #1," purchased specific products at specific stores as shown in "Purchase History #1," and posted as shown in "Posting History #1."

[0134] Here, in the example shown in Figure 12, abstract values ​​such as "U1", "Location History #1", "Search History #1", "Browsing History #1", "Purchase History #1", and "Post History #1" are used for the illustration, but "U1", "Location History #1", "Search History #1", "Browsing History #1", "Purchase History #1", and "Post History #1" are assumed to store specific information such as character strings and numbers.

[0135] The history information database 122 is not limited to the above and may store various types of information depending on the purpose. For example, the history information database 122 may store the user U's usage history of a predetermined service. The history information database 122 may also store the user U's store visit history or facility visit history. The history information database 122 may also store the user U's payment history (electronic payment) using the terminal device 10.

[0136] (Key Information Database 123) The key information database 123 stores various information related to a public key common to the authentication servers in the authentication server group. Fig. 13 is a diagram showing an example of the key information database 123. In the example shown in Fig. 13, the key information database 123 has items such as "key ID," "public key URL," and "user ID."

[0137] The "key ID" indicates identification information for identifying a public key common to the authentication servers in the authentication server group. The "public key URL" indicates a reference DID indicating the location of the public key common to the authentication servers in the authentication server group. Here, the reference DID corresponds to the reference DID linked to the common public key stored in the key registry 200. The "user ID" indicates identification information for identifying the user U who undergoes FIDO authentication using the common public key. In this embodiment, the common public key indicates a common authentication public key.

[0138] For example, in the example shown in Figure 13, the common public key indicated by the key ID "KeyID" is located at the location indicated by the public key URL "DID1" (key registry 200), and if FIDO authentication using the common public key is successful, the user ID "ID1" is extracted.

[0139] Here, in the example shown in Figure 13, abstract values ​​such as "KeyID", "DID1", and "ID1" are used for illustration, but "KeyID", "DID1", and "ID1" are assumed to store specific information such as character strings and numerical values.

[0140] The key information database 123 is not limited to the above and may store various types of information depending on the purpose. For example, the key information database 123 may store identification information for identifying an authentication server group 100G (RP group). The key information database 123 may also store a group list in which the server devices 100 (RPs) in the group are registered. The key information database 123 may also store identification information for identifying the server devices 100 (RPs) in the group. The key information database 123 may also store an authenticator certificate (Attestation) or a certificate of a user verification result (Assertion). The key information database 123 may also store VCs (Verifiable Credentials). The key information database 123 may also store various types of information related to a registration public key common to the authentication servers in the authentication server group, in addition to an authentication public key common to the authentication servers in the authentication server group.

[0141] The storage unit 120 may also store the key registry 200. For example, one of the server devices 100 (RP) in the authentication server group 100G (RP group) may store the key registry 200 in the storage unit 120.

[0142] (control unit 130) 10, the explanation will be continued. The control unit 130 is a controller, and is realized by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like, executing various programs (corresponding to an example of an information processing program) stored in a storage device inside the server device 100 using a storage area such as a RAM as a working area. In the example shown in FIG. 10, the control unit 130 has an acquisition unit 131, a registration processing unit 132, an authentication processing unit 133, and a provision unit 134.

[0143] (Acquisition part 131) The acquisition unit 131 acquires a search query input by a user U. For example, when the user U inputs a search query into a search engine or the like to perform a keyword search, the acquisition unit 131 acquires the search query via the communication unit 110. That is, the acquisition unit 131 acquires, via the communication unit 110, the keywords input by the user U into the search box of a search engine, website, or app.

[0144] Furthermore, the acquisition unit 131 acquires user information about the user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as a user ID) indicating the user U, location information of the user U, attribute information of the user U, etc. from the terminal device 10 of the user U. Furthermore, the acquisition unit 131 may acquire the identification information indicating the user U, attribute information of the user U, etc. when registering the user U. Then, the acquisition unit 131 registers the user information in the user information database 121 of the storage unit 120.

[0145] Furthermore, the acquisition unit 131 acquires various types of history information (log data) indicating the behavior of the user U via the communication unit 110. For example, the acquisition unit 131 acquires various types of history information indicating the behavior of the user U from the terminal device 10 of the user U or from various servers based on the user ID or the like. Then, the acquisition unit 131 registers the various types of history information in the history information database 122 of the storage unit 120.

[0146] (Registration processing unit 132) When the registration processing unit 132 receives a registration request from the terminal device 10 (authentication device) via the communication unit 110, it stores an authentication public key (RP-G authentication public key) common to multiple authentication servers that perform FIDO authentication in the key registry 200. For example, when the registration processing unit 132 receives a registration request from the terminal device 10 (authentication device), it stores, in the key registry 200, on an authentication server group basis, an authentication public key (RP-G authentication public key) common to multiple authentication servers that belong to the same authentication server group.

[0147] Furthermore, the registration processing unit 132 manages a key ID for identifying the common authentication public key (RP-G authentication public key), a public key reference DID (public URL) indicating the location of the common authentication public key (RP-G authentication public key), and a user ID indicating a user who will undergo FIDO authentication using the terminal device 10 (authenticator) by associating them with each other. For example, the registration processing unit 132 associates the key ID, the public key reference DID, and the user ID and registers them in the key information database 123 of the storage unit 120. Furthermore, the key registry 200 manages a key ID for identifying the common authentication public key (RP-G authentication public key), a public key reference DID indicating the location of the common authentication public key (RP-G authentication public key), and the common authentication public key (RP-G authentication public key) by associating them with each other.

[0148] At this time, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a first authentication server, it sends a challenge to the terminal device 10 (authenticator), and receives from the terminal device 10 (authenticator) a signed challenge signed using the registration private key by the terminal device 10 (authenticator) that has succeeded in user verification, and a common authentication public key (RP-G authentication public key) generated by the terminal device 10 (authenticator) that has confirmed that there is no common authentication key pair, and if the signature verification of the signed challenge is successful using the published registration public key, it stores the common authentication public key (RP-G authentication public key) in the key registry 200 and manages it in association with the key ID, the reference DID of the public key, and the first user ID.

[0149] Furthermore, as a second authentication server, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator), it sends a challenge to the terminal device 10 (authenticator), and if there is a common authentication public key (RP-G authentication public key), it receives from the terminal device 10 (authenticator) a signed challenge signed using the registration private key by the terminal device 10 (authenticator) that has successfully verified the user, and if the signature verification of the signed challenge is successful using the published registration public key, it obtains the public key reference DID from the key registry 200 using the key ID, and manages the key ID, public key reference DID, and second user ID in association with each other.

[0150] Alternatively, when the registration processing unit 132, as a second authentication server, receives a registration request from the terminal device 10 (authenticator), it causes the first authentication server to perform a process of sending a challenge to the terminal device 10 (authenticator), and if a common authentication public key (RP-G authentication public key) is present, the terminal device 10 (authenticator) that has successfully verified the user receives from the terminal device 10 (authenticator) a signed challenge signed using the common authentication private key, and if signature verification of the signed challenge is successful using the published registration public key, it causes the terminal device 10 (authenticator) to perform a process of sending the challenge and a group key registration authentication assertion that includes the reference DID of the public key to the terminal device 10 (authenticator).

[0151] (Authentication processing unit 133) When receiving an authentication request from the terminal device 10 (authenticator) via the communication unit 110, the authentication processing unit 133 obtains a common authentication public key (RP-G authentication public key) from the key registry 200 and performs FIDO authentication using the common authentication public key (RP-G authentication public key). For example, when receiving an authentication request from the terminal device 10 (authenticator), the authentication processing unit 133 obtains an authentication public key (RP-G authentication public key) common to multiple authentication servers belonging to the same authentication server group and performs FIDO authentication using the common authentication public key (RP-G authentication public key).

[0152] In addition, when the authentication processing unit 133 receives an authentication request from the terminal device 10 (authenticator) as a second authentication server, it sends a challenge to the terminal device 10 (authenticator), and if a common authentication public key (RP-G authentication public key) is present, the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key (RP-G authentication private key), and if it confirms using the key ID that the reference DID (public URL) of the public key managed in association with the key ID does not exist internally, it may use the key ID to obtain the reference DID of the public key and the common authentication public key (RP-G authentication public key) from the key registry 200, and if signature verification of the signed challenge is successful using the common authentication public key (RP-G authentication public key), it may manage the key ID, the reference DID of the public key, and the second user ID in association with each other.

[0153] Alternatively, as a second authentication server, the authentication processing unit 133 may receive from the terminal device 10 (authenticator) a group key registration authentication assertion that includes a signed challenge signed using a common authentication private key (RP-G authentication public key) by the terminal device 10 (authenticator) that has succeeded in user verification when there is a common authentication public key (RP-G authentication public key) and a public key reference DID; if it confirms using the key ID that the public key reference DID managed in association with the key ID does not exist internally, it may obtain the common authentication public key (RP-G authentication public key) from the key registry 200 using the public key reference DID included in the group key registration authentication assertion; and if signature verification of the signed challenge included in the group key registration authentication assertion is successful using the common authentication public key (RP-G authentication public key), it may manage the key ID, the public key reference DID, and the second user ID in association with each other.

[0154] (Provider 134) If the FIDO authentication is successful, the providing unit 134 provides the service to the terminal device 10 of the user U (or the user U himself or herself, or another device owned by the user U) via the communication unit 110.

[0155] [5. Processing Procedure] Next, processing procedures performed by the server device 100 according to the embodiment will be described with reference to Figs. 14 to 16. Fig. 14 is a flowchart showing a first processing procedure according to the embodiment. Fig. 15 is a flowchart showing a second processing procedure according to the embodiment. Fig. 16 is a flowchart showing a third processing procedure according to the embodiment. The processing procedures shown below are repeatedly executed by the control unit 130 of the server device 100.

[0156] [5-1. First processing procedure] For example, as shown in FIG. 14, the registration processing unit 132 of the server device 100-1 (RP1) belonging to the authentication server group 100G (RP group) receives a registration request from the terminal device 10 (authentication device) of the user U via the communication unit 110 (step S101).

[0157] Next, upon receiving a registration request from the terminal device 10 (authenticator), the registration processing unit 132 of the server device 100-1 (RP1) sends a challenge to the terminal device 10 (authenticator) via the communication unit 110, and receives from the terminal device 10 (authenticator) a signed challenge signed using the registration private key by the terminal device 10 (authenticator) that has successfully verified the user, and a common authentication public key (RP-G authentication public key) generated by the terminal device 10 (authenticator) that has confirmed that there is no common authentication key pair among the server devices 100 (RP) in the group (step S102).

[0158] Next, the registration processing unit 132 of the server device 100-1 (RP1) verifies the signature of the signed challenge using the public registration key that has been made public (step S103).

[0159] Next, if the signature verification of the signed challenge is successful, the registration processing unit 132 of the server device 100-1 (RP1) stores the common authentication public key (RP-G authentication public key) in the key registry 200 and manages the key ID, the reference DID (public URL) of the public key, and the first user ID in association with each other (step S104).

[0160] Next, the registration processing unit 132 of the server device 100-2 (RP2) belonging to the authentication server group 100G (RP group) receives a registration request from the terminal device 10 (authentication device) of the user U via the communication unit 110 (step S201).

[0161] Next, when the registration processing unit 132 of the server device 100-2 (RP2) receives a registration request from the terminal device 10 (authenticator), it sends a group list and a challenge to the terminal device 10 (authenticator) via the communication unit 110, and receives a signed challenge signed by the terminal device 10 (authenticator) that has successfully verified the user using the registration private key from the terminal device 10 (authenticator) that has confirmed that the server devices 100 (RPs) in the group have a common authentication key pair (step S202).

[0162] Next, the registration processing unit 132 of the server device 100-2 (RP2) verifies the signature of the signed challenge using the published registration public key (step S203).

[0163] Next, if the signature verification of the signed challenge is successful, the registration processing unit 132 of the server device 100-2 (RP2) recognizes that it is a group key registration and obtains the reference DID of the public key from the key registry 200 using the key ID (step S204).

[0164] Next, the registration processing unit 132 of the server device 100-2 (RP2) acquires (or generates) a second user ID, and manages the key ID, the reference DID (public URL) of the public key, and the second user ID in association with each other (step S205).

[0165] [5-2. Second processing procedure] Alternatively, as shown in FIG. 15, instead of the processing from step S201 onwards in FIG. 14, the authentication processing unit 133 of the server device 100-2 (RP2) receives a registration request from the terminal device 10 (authentication device) of the user U via the communication unit 110 (step S211).

[0166] Next, when the authentication processing unit 133 of the server device 100-2 (RP2) receives an authentication request from the terminal device 10 (authentication device), it sends a challenge to the terminal device 10 (authentication device) via the communication unit 110, and if there is a common authentication public key (RP-G authentication public key), it receives a signed challenge signed by the terminal device 10 (authentication device) that has succeeded in user verification using the common authentication private key (RP-G authentication private key) (step S212).

[0167] Next, if the authentication processing unit 133 of the server device 100-2 (RP2) uses the key ID to confirm that the reference DID (public URL) of the public key managed in association with the key ID does not exist internally, it uses the key ID to obtain the reference DID of the public key and a common authentication public key (RP-G authentication public key) from the key registry 200 (step S213).

[0168] Next, the authentication processing unit 133 of the server device 100-2 (RP2) verifies the signature of the signed challenge using the common authentication public key (RP-G authentication public key) (step S214).

[0169] Next, if the authentication processing unit 133 of the server device 100-2 (RP2) successfully verifies the signature of the signed challenge using the common authentication public key (RP-G authentication public key), it obtains (or generates) a second user ID and manages the key ID, the reference DID of the public key, and the second user ID in association with each other (step S215).

[0170] [5-3. Third Processing Procedure] Alternatively, as shown in FIG. 16, instead of the processing from step S201 onwards in FIG. 14, when the registration processing unit 132 of the server device 100-2 (RP2) receives a registration request from the terminal device 10 (authentication device), it redirects the request to the server device 100-1 (RP1) in the group via the communication unit 110 (step S221).

[0171] Next, the authentication processing unit 133 of the server device 100-1 (RP1) confirms that a common authentication public key (RP-G authentication public key) already exists, and sends a challenge to the terminal device 10 (authentication device) via the communication unit 110.If a common authentication public key (RP-G authentication public key) exists, the authentication processing unit 133 receives a signed challenge from the terminal device 10 (authentication device) that has successfully verified the user and signed it using the registration private key (step S121).

[0172] Next, if the signature verification of the signed challenge using the common authentication public key (RP-G authentication public key) is successful, the authentication processing unit 133 of the server device 100-1 (RP1) creates a group key registration authentication assertion including the reference DID of the public key, and transmits the challenge and the group key registration authentication assertion to the terminal device 10 (authenticator) via the communication unit 110 (step S122). At this time, the authentication processing unit 133 of the server device 100-1 (RP1) may instruct the terminal device 10 (authenticator) to respond to the server device 100-2 (RP2) in the group. The terminal device 10 (authenticator) transmits the group key registration authentication assertion including the signed challenge signed using the common authentication private key (RP-G authentication private key) and the reference DID of the public key to the server device 100-2 (RP2) via the communication unit 11.

[0173] Next, if a common authentication public key (RP-G authentication public key) already exists, the authentication processing unit 133 of the server device 100-2 (RP2) receives, via the communication unit 110, from the terminal device 10 (authenticator) that has successfully verified the user, an authentication assertion for group key registration that includes a signed challenge signed using the common authentication private key (RP-G authentication private key) and a reference DID of the public key (step S222).

[0174] Next, if the authentication processing unit 133 of the server device 100-2 (RP2) uses the key ID to confirm that the reference DID of the public key managed in association with the key ID does not exist internally, it obtains a common authentication public key (RP-G authentication public key) from the key registry 200 using the reference DID of the public key included in the authentication assertion for group key registration (step S223).

[0175] Next, the authentication processing unit 133 of the server device 100-2 (RP2) verifies the signature of the signed challenge using the common authentication public key (RP-G authentication public key) (step S224).

[0176] Next, if the authentication processing unit 133 of the server device 100-2 (RP2) successfully verifies the signature of the signed challenge included in the group key registration authentication assertion using the common authentication public key (RP-G authentication public key), it manages the key ID, the reference DID of the public key, and the second user ID in association with each other (step S225).

[0177] [6. Modifications] The terminal device 10 (authentication device) and the server device 100 (RP) described above may be implemented in various different forms other than the above embodiment. Therefore, modifications of the embodiment will be described below.

[0178] In the above embodiment, some or all of the processing executed by the server device 100 may actually be executed by the terminal device 10. For example, the processing may be completed in a stand-alone manner (by the terminal device 10 alone). In this case, the terminal device 10 is assumed to have the functions of the server device 100 in the above embodiment. Furthermore, in the above embodiment, the terminal device 10 is linked to the server device 100, and therefore, from the perspective of the user U, it appears that the processing of the server device 100 is also being executed by the terminal device 10. In other words, from another perspective, the terminal device 10 can also be said to be equipped with the server device 100.

[0179] Furthermore, in the above embodiment, the server device 100 is not limited to belonging to one authentication server group (RP group), but may belong to multiple authentication server groups (RP groups). That is, one server device 100 may belong to multiple authentication server groups (RP groups). In this case, the user U may be allowed to select which authentication server group (RP group)'s group key to use ("Which one do you want?"), or the group key found first may be used. That is, it is optional. As long as FIDO authentication can be implemented, any authentication server group (RP group) will do.

[0180] In the above embodiment, the terminal device 10 may determine that the server device 100 belongs to a group of a higher-level domain if the server device 100 belongs to a subdomain. In other words, the terminal device 10 may determine that the group of a higher-level domain is an authentication server group (RP group).

[0181] In the above embodiment, the server device 100 may perform multi-step authentication by combining FIDO authentication with other authentication methods. For example, the server device 100 may perform two-step authentication by combining FIDO authentication with password authentication. Alternatively, the server device 100 may perform two-step authentication by combining FIDO authentication with a secret question.

[0182] In the above embodiment, the server device 100 may perform authentication using a combination of two or more of the three authentication factors, "knowledge information," "possession information," and "biometric information," in FIDO authentication. That is, the server device 100 may employ multi-factor authentication (MFA).

[0183] [7. Effects] As described above, the information processing device (server device 100) of the present application is characterized by comprising: a registration processing unit 132 that stores an authentication public key common to multiple authentication servers that perform FIDO authentication in a key registry 200 when a registration request is received from a terminal device 10 (authenticator); and an authentication processing unit 133 that, when an authentication request is received from the terminal device 10 (authenticator), obtains the common authentication public key from the key registry 200 and performs FIDO authentication using the common authentication public key.

[0184] For example, when receiving a registration request from the terminal device 10 (authenticator), the registration processing unit 132 stores, on an authentication server group basis, an authentication public key common to multiple authentication servers belonging to the same authentication server group in the key registry 200. When receiving an authentication request from the terminal device 10 (authenticator), the authentication processing unit 133 obtains an authentication public key common to multiple authentication servers belonging to the same authentication server group and performs FIDO authentication using the common authentication public key.

[0185] Furthermore, the registration processing unit 132 manages a key ID for identifying a common authentication public key, a public key reference DID indicating the location of the common authentication public key, and a user ID indicating a user who undergoes FIDO authentication using the terminal device 10 (authenticator) in association with each other. The key registry 200 manages a key ID for identifying a common authentication public key, a public key reference DID indicating the location of the common authentication public key, and the common authentication public key in association with each other.

[0186] At this time, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a first authentication server, it sends a challenge to the terminal device 10 (authenticator), and receives from the terminal device 10 (authenticator) a signed challenge signed using the registration private key by the terminal device 10 (authenticator) that has successfully verified the user, and a common authentication public key generated by the terminal device 10 (authenticator) that has confirmed that there is no common authentication key pair, and if the signature verification of the signed challenge is successful using the published registration public key, it stores the common authentication public key in the key registry 200 and manages the key ID, the reference DID of the public key, and the first user ID in association with each other.

[0187] Furthermore, as a second authentication server, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator), it sends a challenge to the terminal device 10 (authenticator), and if a common authentication public key is present, it receives from the terminal device 10 (authenticator) a signed challenge signed using the registration private key by the terminal device 10 (authenticator) that has successfully verified the user, and if the signature verification of the signed challenge is successful using the published registration public key, it obtains the public key reference DID from the key registry 200 using the key ID, and manages the key ID, the public key reference DID, and the second user ID in association with each other.

[0188] Alternatively, when the authentication processing unit 133 receives an authentication request from the terminal device 10 (authenticator) as a second authentication server, it sends a challenge to the terminal device 10 (authenticator), and if a common authentication public key is available, the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key (RP-G authentication private key), and if it confirms using the key ID that the reference DID of the public key managed in association with the key ID does not exist internally, it uses the key ID to obtain the reference DID of the public key and the common authentication public key from the key registry 200, and if signature verification of the signed challenge is successful using the common authentication public key, it manages the key ID, the reference DID of the public key, and the second user ID in association with each other.

[0189] Alternatively, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a second authentication server, it causes the first authentication server to perform a process of sending a challenge to the terminal device 10 (authenticator), and if a common authentication public key is available, the terminal device 10 (authenticator) that has successfully verified the user receives from the terminal device 10 (authenticator) a signed challenge signed using the common authentication private key, and if signature verification of the signed challenge is successful using the published registration public key, sending the challenge and a group key registration authentication assertion including the reference DID of the public key to the terminal device 10 (authenticator). As a second authentication server, the authentication processing unit 133 receives a group key registration authentication assertion from the terminal device 10 (authentication device) that has succeeded in user verification when a common authentication public key is available, the group key registration authentication assertion including a signed challenge signed using a common authentication private key (RP-G authentication private key) and a public key reference DID; if it confirms using the key ID that the public key reference DID managed in association with the key ID does not exist internally, the authentication processing unit 133 obtains the common authentication public key from the key registry 200 using the public key reference DID included in the group key registration authentication assertion; and if signature verification of the signed challenge included in the group key registration authentication assertion using the common authentication public key is successful, the authentication processing unit 133 manages the key ID, the public key reference DID, and the second user ID in association with each other.

[0190] From another perspective, an information processing device (terminal device 10) according to the present application includes, as an authenticator, a group management unit that manages multiple authentication servers that perform FIDO authentication on an authentication server group basis, a transmission unit that transmits a registration request to one of the multiple authentication servers belonging to the same authentication server group, a reception unit that receives a challenge in response to the registration request, a verification unit that creates a signed challenge by signing the challenge using a registration private key if user verification is successful, a confirmation unit that confirms whether or not a common authentication key pair exists among the multiple authentication servers belonging to the authentication server group, and a key generation unit that generates a key pair of an authentication private key and an authentication public key that are common to the multiple authentication servers belonging to the authentication server group if the common authentication key pair exists, and the transmission unit transmits the signed challenge if the common authentication key pair exists.If the common authentication key pair does not exist, the transmission unit transmits the common authentication public key together with the signed challenge.

[0191] The transmitting unit also transmits an authentication request to one of multiple authentication servers belonging to the same authentication server group. The receiving unit receives a challenge in response to the authentication request. If user verification is successful, the verifying unit creates a signed challenge by signing the challenge using a common authentication private key. The confirming unit verifies that a common authentication key pair exists. If a common authentication key pair exists, the transmitting unit transmits the signed challenge.

[0192] Alternatively, the transmitter transmits a key registration request to a second authentication server among multiple authentication servers belonging to the same authentication server group, where the user is not registered. The receiver receives a first challenge from a first authentication server among the multiple authentication servers, where the user is registered. If the user verification is successful, the verifying unit creates a first signed challenge by signing the first challenge using a common authentication private key. The transmitter transmits the first signed challenge to the first authentication server. The receiver receives a second challenge and a group key registration authentication assertion from the first authentication server, the group key registration assertion including the reference DID of the public key. If the user verification is successful, the verifying unit creates a second signed challenge by signing the second challenge using the common authentication private key. The transmitter transmits the group key registration authentication assertion including the second signed challenge and the reference DID of the public key to the second authentication server.

[0193] By performing any one or a combination of the above-described processes, the information processing device according to the present application can further improve the efficiency of authentication.

[0194] [8. Hardware Configuration] The terminal device 10 and the server device 100 according to the above-described embodiments are realized by a computer 1000 having a configuration as shown in Fig. 17, for example. The following description will be given taking the server device 100 as an example. Fig. 17 is a diagram showing an example of a hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which a calculation device 1030, a primary storage device 1040, a secondary storage device 1050, an output I / F (Interface) 1060, an input I / F 1070, and a network I / F 1080 are connected via a bus 1090.

[0195] The arithmetic device 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, programs read from the input device 1020, and the like, and executes various processes. The arithmetic device 1030 is realized by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like.

[0196] The primary storage device 1040 is a memory device such as a RAM (Random Access Memory) that temporarily stores data used by the arithmetic device 1030 for various calculations. The secondary storage device 1050 is a storage device in which data used by the arithmetic device 1030 for various calculations and various databases are registered, and is realized by a ROM (Read Only Memory), an HDD (Hard Disk Drive), an SSD (Solid State Drive), a flash memory, or the like. The secondary storage device 1050 may be an internal storage device or an external storage device. The secondary storage device 1050 may also be a removable storage medium such as a USB (Universal Serial Bus) memory or an SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), a NAS (Network Attached Storage), a file server, or the like.

[0197] The output I / F 1060 is an interface for transmitting information to be output to an output device 1010 that outputs various types of information, such as a display, a projector, a printer, etc., and is realized by a connector conforming to a standard such as USB (Universal Serial Bus), DVI (Digital Visual Interface), or HDMI (High Definition Multimedia Interface), etc. The input I / F 1070 is an interface for receiving information from various input devices 1020, such as a mouse, a keyboard, a keypad, a button, a scanner, etc., and is realized by a USB, etc.

[0198] Furthermore, the output I / F 1060 and the input I / F 1070 may be wirelessly connected to the output device 1010 and the input device 1020, respectively. That is, the output device 1010 and the input device 1020 may be wireless devices.

[0199] The output device 1010 and the input device 1020 may be integrated into one device, such as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated into one device as an input / output I / F.

[0200] The input device 1020 may be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), a DVD (Digital Versatile Disc), or a PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0201] The network I / F 1080 receives data from other devices via the network N and sends it to the arithmetic device 1030, and also transmits data generated by the arithmetic device 1030 to other devices via the network N.

[0202] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output I / F 1060 and the input I / F 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.

[0203] For example, when the computer 1000 functions as the server device 100, the arithmetic unit 1030 of the computer 1000 executes a program loaded onto the primary storage device 1040 to realize the functions of the control unit 130. The arithmetic unit 1030 of the computer 1000 may also load a program acquired from another device via the network I / F 1080 onto the primary storage device 1040 and execute the loaded program. The arithmetic unit 1030 of the computer 1000 may also cooperate with the other device via the network I / F 1080 to call and use the functions and data of a program from another program of the other device.

[0204] [9. Other] Although the embodiments of the present application have been described above, the present invention is not limited to the contents of these embodiments. Furthermore, the above-described components include those that can be easily imagined by a person skilled in the art, those that are substantially the same, and those that are within the scope of so-called equivalents. Furthermore, the above-described components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the spirit of the above-described embodiments.

[0205] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method. In addition, the information including the processing procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, the various information shown in each drawing is not limited to the information shown in the drawings.

[0206] Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0207] For example, the above-mentioned server device 100 may be realized by multiple server computers, and depending on the function, the configuration can be flexibly changed, such as by calling an external platform using an API (Application Programming Interface) or network computing.

[0208] Furthermore, the above-described embodiments and modifications can be combined as appropriate within the scope of not causing any contradiction in the processing content.

[0209] Furthermore, the above-mentioned "section, module, unit" can be read as "means" or "circuit," etc. For example, an acquisition unit can be read as an acquisition means or an acquisition circuit. [Explanation of symbols]

[0210] 1. Information Processing Systems 10 Terminal device (authentication device) 33 Processing section 33A Group Management Department 33B Verification Department 33C Confirmation part 33D key generator 40 Storage section 40A Group List 40B Registration Private Key 40C Authentication Private Key 100G Authentication Server Group (RP Group) 100 Server Device (RP) 110 Communications Department 120 Storage section 121 User Information Database 122 Historical Information Database 123 Key Information Database 130 control section 131 Acquisition Department 132 Registration processing section 133 Authentication processing section 134 Provision Department 200 Key Registry

Claims

1. a registration processing unit that stores an authentication public key common to a plurality of authentication servers that perform FIDO authentication in a key registry when receiving a registration request from the authenticator; an authentication processing unit that, upon receiving an authentication request from the authenticator, obtains the common authentication public key from the key registry and performs FIDO authentication using the common authentication public key; Equipped with the registration processing unit, upon receiving a registration request from the authenticator, stores, in the key registry, an authentication public key common to a plurality of authentication servers belonging to the same authentication server group, on an authentication server group basis; When receiving an authentication request from the authenticator, the authentication processing unit acquires an authentication public key common to a plurality of authentication servers belonging to the same authentication server group, and performs FIDO authentication using the common authentication public key.

1. An information processing device comprising:

2. the registration processing unit manages, in association with each other, a key ID for identifying the common authentication public key, a public key reference DID indicating the location of the common authentication public key, and a user ID indicating a user who will undergo FIDO authentication using the authenticator; The key registry manages a key ID for identifying the common authentication public key, a public key reference DID indicating the location of the common authentication public key, and the common authentication public key in association with each other.

2. The information processing apparatus according to claim 1, wherein:

3. The registration processing unit, as a first authentication server, when receiving a registration request from the authenticator, transmits a challenge to the authenticator, receives from the authenticator a signed challenge signed using a registration private key by the authenticator that has succeeded in user verification, and the common authentication public key generated by the authenticator that has confirmed that the common authentication key pair does not exist, and, when signature verification of the signed challenge is successful using the published registration public key, stores the common authentication public key in the key registry and manages the key ID, the public key reference DID, and the first user ID in association with each other.

3. The information processing apparatus according to claim 2, wherein:

4. The registration processing unit, as a second authentication server, transmits a challenge to the authenticator when receiving a registration request from the authenticator, and receives from the authenticator a signed challenge signed by the authenticator using a registration private key when the common authentication public key is present and the authenticator has successfully verified the user, and when signature verification of the signed challenge is successful using the published registration public key, obtains a public key reference DID from the key registry using a key ID, and manages the key ID, the public key reference DID, and a second user ID in association with each other.

4. The information processing apparatus according to claim 3,

5. The authentication processing unit, as a second authentication server, transmits a challenge to the authenticator upon receiving an authentication request from the authenticator, and when the common authentication public key is present, the authenticator that has succeeded in user verification receives a signed challenge signed using the common authentication private key, and when it has confirmed using a key ID that a reference DID of a public key managed in association with the key ID does not exist internally, acquires the reference DID of the public key and the common authentication public key from the key registry using the key ID, and when signature verification of the signed challenge is successful using the common authentication public key, manages the key ID, the reference DID of the public key, and a second user ID in association with each other.

4. The information processing apparatus according to claim 3,

6. the registration processing unit, as a second authentication server, when receiving a registration request from the authenticator, causes the first authentication server to perform a process of transmitting a challenge to the authenticator, receiving from the authenticator a signed challenge signed using a registration private key by the authenticator that has succeeded in user verification if the common authentication public key is present, and transmitting to the authenticator, if signature verification of the signed challenge is successful using the published registration public key, the challenge and a group key registration authentication assertion including a reference DID of the public key; The authentication processing unit, as a second authentication server, receives from the authenticator the group key registration authentication assertion, which includes a signed challenge signed by the authenticator using a common authentication private key and a public key reference DID, and which has been successfully verified as a user when the common authentication public key is present; if it confirms using a key ID that a public key reference DID managed in association with a key ID does not exist internally, it acquires the common authentication public key from the key registry using the public key reference DID included in the group key registration authentication assertion; and if signature verification of the signed challenge included in the group key registration authentication assertion is successful using the common authentication public key, it manages the key ID, the public key reference DID, and a second user ID in association with each other.

4. The information processing apparatus according to claim 3,

7. a group management unit that manages a plurality of authentication servers that perform FIDO authentication as an authenticator in units of authentication server groups; a transmitter that transmits a registration request to one of a plurality of authentication servers that belong to the same authentication server group; a receiving unit for receiving a challenge in response to the registration request; a verification unit that generates a signed challenge by signing the challenge using a registration private key if user verification is successful; a confirmation unit that confirms whether or not there is a common authentication key pair among a plurality of authentication servers that belong to the authentication server group; a key generating unit that generates a key pair of an authentication private key and an authentication public key that are common to the plurality of authentication servers that belong to the authentication server group when the common authentication key pair does not exist; Equipped with The transmission unit If there is a common authentication key pair, sending the signed challenge; If the common authentication key pair does not exist, send the common authentication public key along with the signed challenge.

1. An information processing device comprising:

8. the transmitting unit transmits an authentication request to one of a plurality of authentication servers belonging to the same authentication server group; the receiving unit receives a challenge to the authentication request; the verification unit creates a signed challenge by signing the challenge using the common authentication private key if the user verification is successful; the verification unit verifies that the common authentication key pair exists, The transmitter transmits the signed challenge if the common authentication key pair exists.

8. The information processing apparatus according to claim 7,

9. the transmitting unit transmits a key registration request to a second authentication server in which the user has not been registered, among a plurality of authentication servers belonging to the same authentication server group; the receiving unit receives a first challenge from a first authentication server among the plurality of authentication servers with which the user has registered; the verification unit creates a first signed challenge by signing the first challenge using a common authentication private key when the user verification is successful; the transmitting unit transmits the first signed challenge to the first authentication server; the receiving unit receives a second challenge and a group key registration authentication assertion including a reference DID of a public key from the first authentication server; the verification unit creates a second signed challenge by signing the second challenge using the common authentication private key if the user verification is successful; The transmitting unit transmits the second signed challenge and the group key registration authentication assertion including a reference DID of a public key to the second authentication server.

9. The information processing apparatus according to claim 8,

10. An information processing method executed by an information processing device, a registration processing step of storing an authentication public key common to multiple authentication servers that perform FIDO authentication in a key registry when a registration request is received from the authenticator; an authentication processing step of acquiring the common authentication public key from the key registry upon receiving an authentication request from the authenticator, and performing FIDO authentication using the common authentication public key; Including, In the registration processing step, when a registration request is received from the authentication device, an authentication public key common to a plurality of authentication servers belonging to the same authentication server group is stored in the key registry for each authentication server group; In the authentication processing step, when an authentication request is received from the authentication device, a public authentication key common to a plurality of authentication servers belonging to the same authentication server group is obtained, and FIDO authentication is performed using the common public authentication key.

1. An information processing method comprising:

11. a registration processing procedure for storing an authentication public key common to multiple authentication servers that perform FIDO authentication in a key registry when a registration request is received from an authenticator; an authentication processing procedure in which, upon receiving an authentication request from the authenticator, the common authentication public key is obtained from the key registry, and FIDO authentication is performed using the common authentication public key; An information processing program for causing a computer to execute the above, In the registration processing step, when a registration request is received from the authenticator, an authentication public key common to a plurality of authentication servers belonging to the same authentication server group is stored in the key registry for each authentication server group; In the authentication processing procedure, when an authentication request is received from the authentication device, a public authentication key common to a plurality of authentication servers belonging to the same authentication server group is obtained, and FIDO authentication is performed using the common public authentication key. An information processing program characterized by:

12. An information processing method executed by an information processing device, a group management process for managing a plurality of authentication servers that perform FIDO authentication as authentication devices in units of authentication server groups; a sending step of sending a registration request to one of a plurality of authentication servers belonging to the same authentication server group; receiving a challenge to the registration request; a verification step of creating a signed challenge by signing the challenge using a registration private key if the user verification is successful; a confirmation step of confirming whether or not there is a common authentication key pair among the plurality of authentication servers belonging to the authentication server group; a key generation step of generating a key pair of an authentication private key and an authentication public key common to the plurality of authentication servers belonging to the authentication server group if the common authentication key pair does not exist; Including, In the transmitting step, If there is a common authentication key pair, sending the signed challenge; If the common authentication key pair does not exist, send the common authentication public key along with the signed challenge.

1. An information processing method comprising:

13. a group management procedure for managing a plurality of authentication servers that perform FIDO authentication as authenticators in units of authentication server groups; a sending step of sending a registration request to one of a plurality of authentication servers belonging to the same authentication server group; a receiving step of receiving a challenge to the registration request; a verification step of creating a signed challenge by signing the challenge using a registration private key if the user verification is successful; a confirmation step of confirming whether or not a common authentication key pair exists among a plurality of authentication servers belonging to the authentication server group; a key generation step of generating a key pair of an authentication private key and an authentication public key common to the plurality of authentication servers belonging to the authentication server group if the common authentication key pair does not exist; on the computer, In the transmission procedure, If there is a common authentication key pair, sending the signed challenge; If the common authentication key pair does not exist, send the common authentication public key along with the signed challenge. An information processing program characterized by:

Images