JP2024060389A - Information processing device, information processing method, and information processing program - Google Patents

Abstract

[Problem] To further improve the efficiency of authentication. [Solution] The information processing device according to the present application is characterized by comprising: a registration processing unit that, when receiving a registration request from an authentication device, stores in a key registry an authentication public key common to multiple authentication servers that perform FIDO authentication, and an authentication processing unit that, when receiving an authentication request from the authentication device, obtains the common authentication public key from the key registry and performs FIDO authentication using the common authentication public key. [Selected Figure] Figure 2

Description

The present invention relates to an information processing device, an information processing method, and an information processing program.

A technology related to FIDO (Fast Identity Online) that uses an authentication device has been disclosed (see Patent Document 1).

JP 2020-141331 A

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

This application was made in consideration of the above, and aims to further improve the efficiency of authentication.

The information processing device according to the present application is characterized by comprising: a registration processing unit that, when receiving a registration request from an authentication device, stores in a key registry an authentication public key common to multiple authentication servers that perform FIDO authentication; and an authentication processing unit that, when receiving an authentication request from the authentication device, obtains the common authentication public key from the key registry and performs FIDO authentication using the common authentication public key.

According to one aspect of the embodiment, the efficiency of authentication can be further improved.

FIG. 1 is an explanatory diagram showing an overview of FIDO authentication. FIG. 2 is an explanatory diagram showing an overview of the information processing method according to the embodiment. FIG. 3 is an explanatory diagram showing an overview of an information system and a trust relationship according to an embodiment. FIG. 4 is an explanatory diagram showing an overview of FIDO registration at RP1. FIG. 5 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP1 and then at RP2. FIG. 6 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP1 and then FIDO authentication is performed at RP2. FIG. 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 via ID federation. FIG. 8 is a diagram illustrating an example of the configuration of an information processing system according to the embodiment. FIG. 9 is a diagram illustrating an example of the configuration of a terminal device according to the embodiment. FIG. 10 is a diagram illustrating an example of the configuration of a server device according to the embodiment. FIG. 11 is a diagram illustrating an example of the user information database. FIG. 12 is a diagram illustrating an example of the history information database. FIG. 13 is a diagram illustrating an example of the key information database. 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. FIG. 17 is a diagram illustrating an example of a hardware configuration.

Below, the information processing device, information processing method, and information processing program according to the present application will be described in detail with reference to the drawings. Note that the information processing device, information processing method, and information processing program according to the present application are not limited to these embodiments. In addition, the same components in the following embodiments will be denoted by the same reference numerals, and duplicated descriptions will be omitted.

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

As shown in FIG. 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.

The terminal device 10 is a smart device such as a smartphone or tablet terminal used by a user U, and is a mobile terminal device capable of communicating with any server device via a wireless communication network such as 4G (Generation) or LTE (Long Term Evolution). The terminal device 10 has a screen such as a liquid crystal display with touch panel functions, and accepts various operations on displayed data such as content, such as tapping, sliding, scrolling, etc., 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 to be 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.

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

For example, FIDO authentication can implement authentication methods that use stored or owned items such as a PIN (Personal Identification Number), a USB (Universal Serial Bus) security key, or a smart card, or authentication methods that use biometric or behavioral information such as a fingerprint, face, iris, vein, or voiceprint. Authentication methods are not limited to these, and any method can be implemented. In addition, multiple authentication methods can be combined to achieve multimodal biometric authentication or multifactor authentication.

In the following, for the sake of simplicity, no distinction will be made between the FIDO client and the authenticator, and the terminal device 10 will be described as both a FIDO client and an authenticator. In other words, the case where the authenticator is an internal authenticator will be described as an example. Note that in reality, the authenticator may be an external authenticator that is physically independent from the terminal device 10 and can be linked to the terminal device 10.

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 a description of this will be omitted in this embodiment.

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/organization that implements a FIDO server. In FIDO authentication, "secrets" such as passwords or biometric information are not shared between the authenticator and the authentication server, making it resistant to phishing.

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 to locally verify the user's identity. The authenticator then signs the challenge with a private key as the verification result, and sends the signed challenge to the authentication server as a signed response. 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.

In this way, in FIDO authentication, the authentication server uses a public key to verify that the authenticator on the user side holds the appropriate private key, thereby achieving authentication. The authenticator and authentication server do not share a "private key."

The server device 100 also functions as a federated RP/SP (Service Provider) that provides identity services through ID federation with an RP/IdP that supports 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.

In the following, for the sake of simplicity, no distinction is made between RP/IdP and linked RP/SP, and the server device 100 is described as both RP/IdP and linked RP/SP. Note that in practice, the server device 100 as RP/IdP and the server device 100 as linked RP/SP may be different, physically independent server devices 100.

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, apps), etc., and various data to the terminal device 10 of each user U.

The server device 100 may also be an information processing device that provides some kind of web service online to the terminal device 10 of each user U. For example, the server device 100 may provide services such as Internet connection, search services, SNS (Social Networking Service), electronic commerce (EC), electronic payment, online games, online banking, online trading, accommodation and ticket reservations, video and music distribution, news, maps, route searches, route guidance, line information, operation information, and weather forecasts as web services. In practice, the server device 100 may cooperate with various servers that provide the above-mentioned web services, and may act as an intermediary for the web services or be responsible for processing the web services.

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 area of residence 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) indicating the user U.

The server device 100 also acquires various 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 location and date and time of the user U, 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 product purchases and payment processing by the user U, from an electronic 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 listings on the marketplace by the user U, from an electronic commerce server or a payment processing server. The server device 100 also acquires a posting history, which is a history of posts by the user U, from a posting server that provides a word-of-mouth posting service or an SNS server. The various servers and the like described above may be the server device 100 itself. In other words, the server device 100 may function as the various servers and the like described above.

[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 a FIDO server function) that supports FIDO authentication, it is necessary to register a key for each IdP individually, which is troublesome for users. In addition, the IdP needs to manage the keys, which imposes a burden on the implementation and operation for management.

Therefore, in this embodiment, a public key cryptography-based authentication system (FIDO multi-server credentials) is realized that allows 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 commonly by multiple authentication servers, 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.

Figure 2 is an explanatory diagram showing an overview of an information processing method according to an embodiment. In this embodiment, there are multiple server devices 100, which are authentication servers. Each of the multiple 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.

For example, as shown in FIG. 2, user U holds accounts ID1 and ID2 on server device 100-1 (RP1) and server device 100-2 (RP2), respectively. That is, user U holds account ID1 on server device 100-1 (RP1) and account ID2 on server device 100-2 (RP2).

The terminal device 10 (authenticator) also 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 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.

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 of them has a user ID management function. RP1 manages a user's account ID1, and RP2 manages a user's 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.

The key registry 200 also stores a public key that can be used in common by multiple authentication servers. The key registry 200 may be a storage server on the network N (see FIG. 8), or may be one of the multiple server devices 100 (RP) belonging to the 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.

[1-2. System Overview]
Fig. 3 is an explanatory diagram showing an overview of an information system and a trust relationship 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).

Furthermore, there is cryptographically constructed trust 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 Figure 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).

In addition, 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 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 Figure 3, there is trust established by FIDO authentication with both server device 100-1 (RP1) and server device 100-2 (RP2) belonging to authentication server group 100G (RP group).

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

In this embodiment, there is a one-to-one relationship between a key pair and an authentication server group, but 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 a one-to-one relationship between a registration key pair and an authentication server. The registration key pair is, for example, a key pair for signature verification of an authenticator certificate (Attestation). The authentication key pair is, for example, a key pair for signature verification of a certificate (Assertion) of the user verification result in the authenticator. In other words, the registration key pair (attestation key pair) is the same as before.

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, it is also possible to store a common registration public key that can be commonly used for multiple authentication servers in the key registry 200, similar to the authentication public key.

[1-3. FIDO registration with RP1]
Fig. 4 is an explanatory diagram showing an overview of FIDO registration at RP1. 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 of the user U (step S0).

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) together with a registration request for FIDO to 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 data string that is different each time and is determined based on random numbers. The server device 100-1 (RP1) and the server device 100-2 (RP2) that are the registration destinations are registered in the group list. That is, the server device 100-1 (RP1) transmits a group list (RP-G list) related to 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) together with the challenge.

The user U performs user verification using the terminal device 10 (authentication device) and performs local verification of the user's identity (step S2). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

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 verifies that the server devices 100 (RP) in the group do not have a common authentication key pair (RPG-G authentication key pair), and generates an authentication key pair (RPG-G authentication key pair) (step S3). The terminal device 10 (authenticator) stores the authentication private key (RPG-G authentication private key) common to the server devices 100 (RP) in the group. The terminal device 10 (authenticator) may store the authentication server group (RPG-G) and the common authentication private key (RPG-G authentication private key) in association with each other.

Then, the terminal device 10 (authenticator) 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).

Next, when the server device 100-1 (RP1) receives the signed challenge (attestation document), it verifies the signature using the registration public key (attestation public key) (step S5).

Next, if the signature verification is successful, the server device 100-1 (RP1) stores the authentication public key (RPG-G authentication public key) common to the server devices 100 (RP) in the group in the key registry 200, and stores the authentication public key common to the server devices 100 (RP) in the group in association with the user ID (ID1) of the user U (step S6). In the example of FIG. 3, the server device 100-1 (RP1) manages the key ID for identifying the authentication public key common to the server devices 100 (RP) in the group, the 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 in association with each other. The key registry 200 manages the authentication public key (RPG-G authentication public key) in association with the reference DID (DID1) of the authentication public key (RPG-G authentication public key).

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

[1-4. FIDO registration with 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, a 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 of the user U (step S10). This registration request is a registration request for a group key based on a group list.

Next, in response to a registration request from the terminal device 10 (authenticator) of user U, the server device 100-2 (RP2) transmits a challenge to the terminal device 10 (authenticator) of user U via the network N (see FIG. 10) along with a request to register FIDO 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.

The user U performs user verification using the terminal device 10 (authentication device) and performs local verification of the user's identity (step S12). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

Next, if the user verification is successful, the terminal device 10 (authenticator) 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, the server devices 100 (RP) in the group already have a common authentication private key (RP-G authentication private key), but here the "attestation private key" is used in accordance with the original FIDO registration process.

Then, the terminal device 10 (authenticator) sends a signed challenge (attestation document) signed with the registration private key (attestation private key) and an authentication public key (RPG-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).

Next, when the server device 100-2 (RP2) receives the signed challenge (attestation document), it verifies the signature using the registration public key (attestation public key) (step S15).

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

Note that the server device 100-2 (RP2) belonging to the 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, it recognizes this as a legitimate group key registration in the processing of step S16 and proceeds with the processing.

Then, the server device 100-2 (RP2) acquires (or generates) the user ID (ID2) of the user U at RP2 and completes the authentication (step S17). For example, if the user U is already registered in an existing service or the like at RP2, the server device 100-2 (RP2) acquires the user ID (ID2) of the registered user U, and if the user U is unregistered, it newly generates (issues) a user ID (ID2) for the new user U. At this time, the server device 100-2 (RP2) manages by linking 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).

[1-5. FIDO authentication at RP2]
Fig. 6 is an explanatory diagram showing an overview of a case where FIDO registration is performed at RP1 and then FIDO authentication is performed at RP2. For example, as shown in Fig. 6, a 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 of the user U (step S20).

Next, in response to an authentication request from the terminal device 10 (authenticator) of user U, the server device 100-2 (RP2) transmits a challenge to the terminal device 10 (authenticator) of 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.

The user U performs user verification using the terminal device 10 (authentication device) and performs local verification of the user's identity (step S22). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

Next, if the user verification is successful, the terminal device 10 (authenticator) 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 (RPG-G authentication private key), and generates an assertion document (step S23). Here, the terminal device 10 uses the existing RPG-G authentication private key that was generated when registering FIDO to the server device 100-1 (RP1) shown in Figure 4.

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

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 FIG. 10), it uses the key ID, but when it confirms that there is no public key URL because it is unregistered, it uses the key ID to obtain the reference DID (DID1) of the authentication public key (RPG-G authentication public key) and the authentication public key (RPG-G authentication public key) from the key registry 200 (step S25).

As a method of confirming that there is no public key URL, for example, when 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. As it is assumed that this is the first time key registration is being performed for 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) (empty).

Then, the server device 100-2 (RP2) uses the authentication public key (RPG authentication public key) to verify the signature of the signed challenge (assertion document) (step S26).

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 by linking together a key ID (keyID) for identifying the 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).

[1-6. Register with RP2 by linking ID]
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, a terminal device 10 (authentication device) of a user U (user) transmits a group key 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 of the user U (step S30).

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, the server device 100-1 (RP1) transmits a challenge to the terminal device 10 (authenticator) of the user U, together with a FIDO authentication request to the authentication server group 100G (RP group) and the server device 100-2 (RP2) via the network N (see FIG. 10) (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 server device 100-2 (RP2) receives a group key registration request from terminal device 10 (authentication device) of user U (user), it may redirect the request to server device 100-1 (RP1) where the group key has already been registered.

The user U performs user verification using the terminal device 10 (authentication device) and performs local verification of the user's identity (step S32). For example, the terminal device 10 (authentication device) performs biometric authentication based on biometric information acquired from the user U.

Next, if the user verification is successful, the terminal device 10 (authenticator) confirms that the server device 100 (RP) in the group has a common authentication private key (RPG-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 (RPG-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-ID2 are federated between RP1-RP2).

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

Next, when the server device 100-1 (RP1) receives the signed challenge (assertion document), it creates an authentication assertion for group key registration (assertion document, including DID1) and transmits the authentication assertion for group key registration (assertion document, including DID1) to the terminal device 10 (authenticator) of user U via the network N (see FIG. 10) (step S35). That is, the authentication assertion for group key registration includes the signed challenge (assertion document) and the reference DID (DID1) of the authentication public key.

At this time, 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 (RPG authentication public key), and if the signature verification is successful, create an authentication assertion for group key registration (assertion document, including DID1).

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

Next, when the server device 100-2 (RP2) receives the group key registration authentication assertion (including the assertion document, DID1) from the terminal device 10 (authenticator) of the user U via the network N (see FIG. 10), it uses the key ID, but when it confirms that there is no public key URL because it has not been 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 (RPG authentication public key) from the key registry 200 (step S37).

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).

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) 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.

[1-7. Updating/deleting group keys, updating group lists]
In the above example, only the process for registering a common public key (group key) has been described. However, 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.

[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 key management for FIDO.

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

In addition, the authentication server simplifies identity management and reduces management costs because public key management is no longer necessary.

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 a 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 by wire or wirelessly. The network N is, for example, a local area network (LAN) or a wide area network (WAN) such as the Internet.

Furthermore, the number of devices included in the information processing system 1 shown in FIG. 8 is not limited to that shown. For example, in FIG. 8, only one terminal device 10 is shown to simplify the illustration, but this is merely an example and is not limiting, and there may be two or more devices.

The terminal device 10 is an information processing device used by a user U. For example, the terminal device 10 is a smart device such as a smartphone or tablet terminal, a mobile phone such as a feature phone, a personal computer (PC), a personal digital assistant (PDA), a game console or AV device with communication functions, information appliances or digital appliances, 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).

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.

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

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.

(Communication unit 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 network interface card (NIC), an antenna, or the like.

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

(Input unit 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) or a Universal Serial Bus (USB) port, and the like. In addition, when the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. In addition, the input unit 13 may be a microphone that accepts voice input from the user U, and the like. The microphone may be wireless.

(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 based on the received signals. That is, the positioning unit 14 measures the position of the terminal device 10. Note that the GPS is merely an example of a GNSS (Global Navigation Satellite System).

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 using various communication functions of the terminal device 10 as an auxiliary positioning means for position correction, etc., as described below.

(Wi-Fi positioning)
For example, the positioning unit 14 uses the 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 to measure the position of the terminal device 10.

(Beacon positioning)
Furthermore, the positioning unit 14 may 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.

(geomagnetic positioning)
In addition, the positioning unit 14 locates 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 provided in the terminal device 10 .

(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, stores, etc., or has a function of reading an RFID tag, the location of use is recorded together with information on a payment or the like made by the terminal device 10. The positioning unit 14 may obtain such information to measure the location of the terminal device 10. Furthermore, the location may be measured by an optical sensor, an infrared sensor, or the like provided in the terminal device 10.

If necessary, the positioning unit 14 may use one or a combination of the positioning means described above to determine the position of the terminal device 10.

(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 and wireless devices. In the example shown in FIG. 9, the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, an air 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.

Note that the above-mentioned sensors 21 to 28 are merely examples and are not limiting. In other words, 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.

The acceleration sensor 21 is, for example, a three-axis acceleration sensor, and detects the physical movement of the terminal device 10, such as the direction of movement, speed, and acceleration of the terminal device 10. The gyro sensor 22 detects the physical movement of the terminal device 10, such as the 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.

Since the terminal device 10 is equipped with the above-mentioned acceleration sensor 21, gyro sensor 22, air pressure sensor 23, etc., it is possible to determine the position of the terminal device 10 using technology such as Pedestrian Dead-Reckoning (PDR) that utilizes these sensors 21 to 23. This makes it possible to obtain indoor position information that is difficult to obtain using positioning systems such as GPS.

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 gyro sensor 22 can be used to know the user U's direction of travel, line of sight, and body inclination. In addition, the air pressure detected by the air pressure sensor 23 can be used to know the altitude and floor on which the user U's terminal device 10 is located.

The air temperature sensor 24 detects, for example, the air temperature around the terminal device 10. The sound sensor 25 detects, for example, 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.

The above-mentioned air pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the environment and situation around the terminal device 10 by detecting air pressure, temperature, sound, and illuminance, and capturing images of the surroundings. In addition, it becomes possible to improve the accuracy of the location information of the terminal device 10 based on the environment and situation around the terminal device 10.

(Control unit 30)
The control unit 30 includes, for example, a microcomputer having a central processing unit (CPU), a read only memory (ROM), a RAM, an input/output port, and various other circuits. The control unit 30 may also be configured with hardware such as an integrated circuit, for example, an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The control unit 30 includes a transmitting unit 31, a receiving unit 32, and a processing unit 33.

(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.

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

(Processing Unit 33)
The processing unit 33 controls the entire terminal device 10, including the display unit 12, etc. For example, the processing unit 33 can output various information transmitted by the transmission unit 31 and various information received from the server device 100 by the reception unit 32 to the display unit 12 for display.

The processing unit 33 also 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.

(Group management unit 33A)
The group management unit 33A manages a plurality of 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 plurality of 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. Also, the transmission unit 31 transmits an authentication request to one of the plurality of 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 that is not registered with a user among the plurality of authentication servers (server devices 100) that belong to the same authentication server group. The reception unit 32 receives a first challenge from a first authentication server that is registered with a user among the plurality of authentication servers (server devices 100).

(Verification unit 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 with a 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 with a common authentication private key.

If user verification is successful, the verification unit 33B creates a first signed challenge by signing the first challenge using a 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.

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.

(Confirmation unit 33C)
The verification unit 33C verifies whether or not a common authentication key pair exists among a plurality of authentication servers (server devices 100) belonging to the authentication server group. At this time, the transmission unit 31 transmits a signed challenge if a common authentication key pair exists.

(Key generation unit 33D)
If there is no common authentication key pair, the key generating unit 33D generates a key pair of an authentication private key and an authentication public key 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 transmitting unit 31 transmits the common authentication public key together with the signed challenge.

(Memory unit 40)
The storage unit 40 is realized by, for example, a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk drive (HDD), a solid state drive (SSD), an optical disk, etc. Various programs and various data are stored in the storage unit 40.

In addition, the secure area (secure element) of the storage unit 40 stores the group list 40A, the registration private key 40B, and the authentication private key 40C. 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 reality, the group list 40A, the registration private key 40B, and the authentication private key 40C may be stored in association with each other, or the registration private key 40B and the authentication private key 40C may be included in the group list 40A. Also, 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 the normal area.

The group list 40A is data that registers multiple server devices 100 (RP) that belong to the same authentication server group 100G (RP group) on an authentication server group basis. For example, the group list 40A is data in a list format that registers the URLs, etc., of the server devices 100 in the group. Note that the data format is not limited to a list format, and may 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.

The registration private key 40B is a registration private key (attestation private key) of a conventional registration key pair. However, in reality, the 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, on an authentication server group basis, similar to the authentication private key 40C.

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. In other words, the authentication private key 40C is an authentication private key (RPG authentication private key) common to the server devices 100 (RP) in the group.

4. Example of Server Device Configuration
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.

(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) in a wired or wireless manner.

(Memory unit 120)
The storage unit 120 is realized by, for example, a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a 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.

(User Information Database 121)
The user information database 121 stores user information related to 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".

"User ID" indicates identification information for identifying user U. Note that "user ID" may be contact information for user U (telephone number, email address, etc.) or may be identification information for identifying user U's terminal device 10.

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 information indicating the generation of user U (e.g., 30s). Alternatively, "age" may be information indicating user U's date of birth or information indicating user U's generation (e.g., born in the 1980s). Furthermore, "gender" indicates the gender of user U identified by the user ID.

"Home" indicates the location information of the home of user U, which is 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. For example, "Home" may also be the name of a region or an address.

"Workplace" indicates the 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. For example, "workplace" may also be the name of a region or an address.

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. Note that, although one "interest" is illustrated for each user U in the example shown in FIG. 11, there may be multiple "interests."

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, user U identified by user ID "U1" indicates that his/her home address is "LC11." Furthermore, for example, user U identified by user ID "U1" indicates that his/her workplace is "LC12." Furthermore, for example, user U identified by user ID "U1" indicates that he/she is interested in "sports."

In the example shown in FIG. 11, abstract values such as "U1", "LC11", and "LC12" are used to illustrate the data, but it is assumed that concrete information such as character strings and numerical values is stored in "U1", "LC11", and "LC12". In the following figures relating to other information, abstract values may also be illustrated.

The user information database 121 may store various information according to the purpose, not limited to the above. For example, the user information database 121 may store various information related to the terminal device 10 of the user U. The user information database 121 may also store information related to the attributes of the user U, 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, place of origin (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 section (station, line, etc.), frequently used station (other than the nearest station to home or workplace), extracurricular activities (location, time period, etc.), hobbies, interests, and lifestyle.

(History information database 122)
The history information database 122 stores various information related to history information (log data) indicating 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".

"User ID" refers to identification information for identifying user U. "Location history" refers to location history, which is a history of user U's location and movements. "Search history" refers to search history, which is a history of search queries entered by user U. "Browse history" refers to browse history, which is a history of content viewed by user U. "Purchase history" refers to purchase history, which is a history of purchases made by user U. "Post history" refers to posting history, which is a history of posts made by user U. "Post history" may include questions about user U's possessions.

For example, in the example shown in FIG. 12, user U identified by user ID "U1" moves as shown in "location history #1", searches as shown in "search history #1", views content as shown in "browsing history #1", purchases specific products etc. at specific stores etc. as shown in "purchase history #1", and posts as shown in "post history #1".

In the example shown in FIG. 12, abstract values such as "U1", "Location History #1", "Search History #1", "Browse History #1", "Purchase History #1", and "Post History #1" are used for illustration, but it is assumed that specific information such as character strings and numerical values is stored in "U1", "Location History #1", "Search History #1", "Browse History #1", "Purchase History #1", and "Post History #1".

The history information database 122 may store various information depending on the purpose, not limited to the above. For example, the history information database 122 may store the usage history of a specific service by the user U. The history information database 122 may also store the history of the user U's visit to a physical store or the history of the user U's visit to a facility. The history information database 122 may also store the payment history of payments (electronic payments) made using the user U's terminal device 10.

(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".

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 receives FIDO authentication using the common public key. In this embodiment, the common public key indicates a common authentication public key.

For example, in the example shown in FIG. 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.

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

The key information database 123 may store various information according to the purpose, not limited to the above. For example, the key information database 123 may store identification information for identifying the authentication server group 100G (RP group). The key information database 123 may store a group list in which the server device 100 (RP) in the group is registered. The key information database 123 may store identification information for identifying the server device 100 (RP) in the group. The key information database 123 may store an authenticator certificate (Attestation) or a certificate of a user verification result (Assertion). The key information database 123 may store VC (Verifiable Credentials). The key information database 123 may store various information related to a registration public key common to the authentication servers in the authentication server group, not limited to an authentication public key common to the authentication servers in the authentication server group.

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.

(Control unit 130)
Returning to Fig. 10, the description will be continued. The control unit 130 is a controller, and is realized by, for example, a central processing unit (CPU), a micro processing unit (MPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), 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.

(Acquisition unit 131)
The acquisition unit 131 acquires a search query input by a user U (user). 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 keywords input by the user U into a search box of a search engine, a site, or an app via the communication unit 110.

The acquisition unit 131 also acquires user information related to user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as a user ID) indicating user U, location information of user U, attribute information of user U, etc. from the terminal device 10 of user U. The acquisition unit 131 may also acquire identification information indicating user U, attribute information of user U, etc. when user U is registered. Then, the acquisition unit 131 registers the user information in the user information database 121 of the storage unit 120.

The acquisition unit 131 also 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, etc. based on the user ID, etc. Then, the acquisition unit 131 registers the various types of history information in the history information database 122 of the storage unit 120.

(Registration Processing Unit 132)
When the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) via the communication unit 110, it stores an authentication public key (RPG-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 (authenticator), it stores, in the key registry 200, an authentication public key (RPG-G authentication public key) common to multiple authentication servers belonging to the same authentication server group, on an authentication server group basis.

The registration processing unit 132 also manages a key ID for identifying the common authentication public key (RPG-G authentication public key), a public key reference DID (public URL) indicating the location of the common authentication public key (RPG-G authentication public key), and a user ID indicating the user who will undergo FIDO authentication using the terminal device 10 (authenticator) by linking them together. For example, the registration processing unit 132 links 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. The key registry 200 also manages a key ID for identifying the common authentication public key (RPG-G authentication public key), a public key reference DID indicating the location of the common authentication public key (RPG-G authentication public key), and the common authentication public key (RPG-G authentication public key) by linking them together.

At this time, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as the first authentication server, it sends a challenge to the terminal device 10 (authenticator), 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 (RPG-G authentication public key) generated by the terminal device 10 (authenticator) that has confirmed that there is no common authentication key pair, and if signature verification of the signed challenge is successful using the published registration public key, it stores the common authentication public key (RPG-G 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.

In addition, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a second authentication server, it sends a challenge to the terminal device 10 (authenticator), and if there is a common authentication public key (RPG-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.

Alternatively, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a second authentication server, the registration processing unit 132 causes the first authentication server to perform a process of sending a challenge to the terminal device 10 (authenticator), and if there is a common authentication public key (RPG-G authentication public key), the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key from the terminal device 10 (authenticator), and if the 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).

(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 (RPG-G authentication public key) from the key registry 200 and performs FIDO authentication using the common authentication public key (RPG-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 (RPG-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 (RPG-G authentication public key).

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 there is a common authentication public key (RPG-G authentication public key), the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key (RPG-G authentication private key), and if it is confirmed 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 uses the key ID to obtain the reference DID of the public key and the common authentication public key (RPG-G authentication public key) from the key registry 200, and if the signature verification of the signed challenge is successful using the common authentication public key (RPG-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.

Alternatively, the authentication processing unit 133 may, as a second authentication server, receive from the terminal device 10 (authenticator) a group key registration authentication assertion including a signed challenge signed using a common authentication private key (RPG-G authentication public key) and a public key reference DID when the terminal device 10 (authenticator) that has successfully verified the user has a common authentication public key (RPG-G authentication public key), and if it is confirmed using the key ID that the public key reference DID managed in association with the key ID does not exist internally, obtain a common authentication public key (RPG-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 the signature verification of the signed challenge included in the group key registration authentication assertion is successful using the common authentication public key (RPG-G authentication public key), manage the key ID, the public key reference DID, and the second user ID in association with each other.

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

5. Processing Procedure
Next, the processing procedure 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. Note that the processing procedure shown below is repeatedly executed by the control unit 130 of the server device 100.

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).

Next, when the registration processing unit 132 of the server device 100-1 (RP1) receives a registration request from the terminal device 10 (authenticator), it 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 (RPG authentication public key) generated by the terminal device 10 (authenticator) that has confirmed that the server devices 100 (RP) in the group do not have a common authentication key pair (step S102).

Then, the registration processing unit 132 of the server device 100-1 (RP1) verifies the signature of the signed challenge using the published registration public key (step S103).

Next, if the registration processing unit 132 of the server device 100-1 (RP1) is successful in verifying the signature of the signed challenge, it stores the common authentication public key (RPG-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).

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).

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 transmits 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 (RP) in the group have a common authentication key pair (step S202).

Then, 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).

Next, if the registration processing unit 132 of the server device 100-2 (RP2) is successful in verifying the signature of the signed challenge, it recognizes that this 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).

Then, 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).

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) accepts a registration request from the terminal device 10 (authentication device) of user U via the communication unit 110 (step S211).

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

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 (RPG-G authentication public key) from the key registry 200 (step S213).

Then, 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 (RPG authentication public key) (step S214).

Next, if the authentication processing unit 133 of the server device 100-2 (RP2) is successful in verifying the signature of the signed challenge using the common authentication public key (RPG-G authentication public key), it acquires (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).

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

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

Next, if the authentication processing unit 133 of the server device 100-1 (RP1) succeeds in verifying the signature of the signed challenge using the common authentication public key (RPG-G authentication public key), it 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 (RPG-G authentication private key) and the reference DID of the public key to the server device 100-2 (RP2) via the communication unit 11.

Next, if a common authentication public key (RPG-G authentication public key) is already present, 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 (RPG-G authentication private key) and a reference DID for the public key (step S222).

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 (RPG 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).

Then, 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 (RPG authentication public key) (step S224).

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 (RPG 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).

6. Modifications
The above-described terminal device 10 (authentication device) and server device 100 (RP) may be implemented in various different forms other than the above embodiment. Therefore, the following describes modified examples of the embodiment.

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. Also, in the above embodiment, since the terminal device 10 is linked to the server device 100, from the perspective of the user U, it appears that the processing of the server device 100 is also executed by the terminal device 10. In other words, from another perspective, it can also be said that the terminal device 10 is equipped with the server device 100.

In addition, 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 would you like?"), or the first one found may be used. In other words, it is optional. As long as FIDO authentication can be implemented, it does not matter which authentication server group (RP group) is used.

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

In addition, in the above embodiment, the server device 100 may combine FIDO authentication with other authentication to provide multi-step authentication. For example, the server device 100 may combine FIDO authentication with password authentication to provide two-step authentication. Alternatively, the server device 100 may combine FIDO authentication with a secret question to provide two-step authentication.

In addition, in the above embodiment, the server device 100 may perform authentication using a combination of two or more of the three elements of authentication, namely, "knowledge information," "possession information," and "biometric information," in FIDO authentication. In other words, the server device 100 may employ multi-factor authentication (MFA).

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, in a key registry 200, an authentication public key common to multiple authentication servers that perform FIDO authentication 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.

For example, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator), it stores an authentication public key common to multiple authentication servers belonging to the same authentication server group in the key registry 200 on an authentication server group basis. When the authentication processing unit 133 receives an authentication request from the terminal device 10 (authenticator), it 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.

The registration processing unit 132 also 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 a user ID indicating the user who will undergo FIDO authentication using the terminal device 10 (authenticator) in association with each other. The key registry 200 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.

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), 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 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.

In addition, when the registration processing unit 132 receives a registration request from the terminal device 10 (authenticator) as a second authentication server, it sends a challenge to the terminal device 10 (authenticator), and if there is a common 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, the public key reference DID, and the second user ID in association with each other.

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 there is a common authentication public key, the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key (RPG authentication private key), and if it 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 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.

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 is present, the terminal device 10 (authenticator) that has successfully verified the user receives a signed challenge signed using the common authentication private key from the terminal device 10 (authenticator), 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 a reference DID of the public key to the terminal device 10 (authenticator). The authentication processing unit 133, as a second authentication server, receives from the terminal device 10 (authenticator) a group key registration authentication assertion that includes a signed challenge signed by the terminal device 10 (authenticator) using a common authentication private key (RPG-G authentication private key) and a public key reference DID when the terminal device 10 (authenticator) that has succeeded in user verification when there is a common authentication public key, and if it is confirmed using the key ID that the public key reference DID managed in association with the key ID does not exist internally, it obtains a 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, it manages the key ID, the public key reference DID, and the second user ID in association with each other.

From another perspective, the 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 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 there is a common authentication key pair for multiple authentication servers belonging to the authentication server group, and a key generation unit that generates a key pair of a common authentication private key and authentication public key for multiple authentication servers belonging to the authentication server group if there is no common authentication key pair, and the transmission unit transmits the signed challenge if there is a common authentication key pair. If there is no common authentication key pair, it transmits the common authentication public key together with the signed challenge.

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.

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

By using any one or a combination of the above-mentioned processes, the information processing device according to the present application can further improve the efficiency of authentication.

8. Hardware Configuration
Moreover, the terminal device 10 and the server device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration as shown in Fig. 17, for example. The server device 100 will be described below 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 by a bus 1090.

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, for example, by 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.

The primary storage device 1040 is a memory device such as a RAM (Random Access Memory) that primarily 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), a HDD (Hard Disk Drive), a 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 be a removable storage medium such as a USB (Universal Serial Bus) memory or a SD (Secure Digital) memory card. The secondary storage device 1050 may be a cloud storage device (online storage device), a NAS (Network Attached Storage), a file server, or the like.

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, projector, printer, etc., and is realized by a connector conforming to a standard such as USB (Universal Serial Bus), DVI (Digital Visual Interface), or HDMI (registered trademark) (High Definition Multimedia Interface). The input I/F 1070 is an interface for receiving information from various input devices 1020, such as a mouse, keyboard, keypad, button, scanner, etc., and is realized by a USB, etc.

In addition, 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.

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

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.

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

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.

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 other devices via the network I/F 1080 and use the functions and data of a program by calling them from other programs of the other devices.

[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. The above-described components include those that a person skilled in the art can easily imagine, those that are substantially the same, and those that are within the so-called equivalent range. Furthermore, the above-described components can be appropriately combined. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the spirit of the above-described embodiments.

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 known methods. 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.

In addition, each component of each device shown in the figure is a functional concept, and does 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.

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

The above-described embodiments and variations can be combined as appropriate to the extent that they do not cause inconsistencies in the processing content.

In addition, the above-mentioned "section, module, unit" can be read as "means" or "circuit." For example, an acquisition unit can be read as an acquisition means or an acquisition circuit.

1 Information processing system 10 Terminal device (authentication device)
33 Processing unit 33A Group management unit 33B Verification unit 33C Confirmation unit 33D Key generation unit 40 Storage unit 40A Group list 40B Registration private key 40C Authentication private key 100G Authentication server group (RP group)
100 Server device (RP)
REFERENCE SIGNS LIST 110 Communication unit 120 Storage unit 121 User information database 122 History information database 123 Key information database 130 Control unit 131 Acquisition unit 132 Registration processing unit 133 Authentication processing unit 134 Provision unit 200 Key registry

Claims (14)

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 a registration request is received from the authentication device;
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;
An information processing device comprising: when receiving a registration request from the authentication device, the registration processing unit 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;
The information processing device according to claim 1, characterized in that, when receiving an authentication request from the authentication device, 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. 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 is to undergo FIDO authentication using the authentication device;
The information processing device according to claim 1, characterized in that 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. 4. The information processing device according to claim 3, wherein 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 a published registration public key, stores the common authentication public key in the key registry and manages a key ID, a reference DID of the public key, and a first user ID in association with each other. 5. The information processing device according to claim 4, wherein the registration processing unit, as a second authentication server, when receiving a registration request from the authentication device, transmits a challenge to the authentication device, and when the common authentication public key is present, receives from the authentication device a signed challenge signed by the authentication device that has succeeded in user verification using a registration private key, and when signature verification of the signed challenge is successful using a 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. 5. The information processing device according to claim 4, wherein the authentication processing unit, as a second authentication server, when receiving an authentication request from the authentication device, sends a challenge to the authentication device, and when the common authentication public key is present, the authentication device that has succeeded in user verification receives a signed challenge signed using the common authentication private key, and when it is confirmed using a key ID that a reference DID of a public key managed in association with a key ID does not exist internally, obtains a reference DID of a 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 a public key, and a second user ID in association with each other. the registration processing unit, as a second authentication server, when receiving a registration request from the authenticator, causes a first authentication server to execute a process of transmitting a challenge to the authenticator, receiving from the authenticator a signed challenge signed by the authenticator that has succeeded in user verification using a registration private key when the common authentication public key is present, and transmitting to the authenticator a challenge and a group key registration authentication assertion including a reference DID of a public key when signature verification of the signed challenge using a published registration public key is successful;
5. The information processing device according to claim 4, wherein the authentication processing unit, as a second authentication server, receives from the authenticator the group key registration authentication assertion including a signed challenge signed by the authenticator that has succeeded in user verification using a common authentication private key and a public key reference DID, and when it is confirmed using a key ID that a public key reference DID managed in association with a key ID does not exist internally, obtains the common authentication public key from the key registry using the public key reference DID included in the group key registration authentication assertion, and when signature verification of the signed challenge included in the group key registration authentication assertion is successful using the common authentication public key, manages the key ID, the public key reference DID, and a second user ID in association with each other. 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 transmission unit 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 to the registration request;
a verification unit that creates a signed challenge by signing the challenge using a registration private key when the user verification is successful;
a confirmation unit that confirms whether or not a common authentication key pair exists 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 belonging to the authentication server group when the common authentication key pair does not exist;
Equipped with
The transmission unit is
sending the signed challenge if there is a common authentication key pair;
If the common authentication key pair does not exist, the information processing device transmits the common authentication public key together with the signed challenge. the transmission 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 when the user verification is successful;
The verification unit verifies that the common authentication key pair exists,
The information processing apparatus according to claim 8 , wherein the transmission unit transmits the signed challenge when the common authentication key pair is present. the transmission 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 in which a user has been registered among the plurality of authentication servers;
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 when the user verification is successful;
The information processing device according to claim 8 , wherein the transmission 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. An information processing method executed by an information processing device,
a registration process step of storing an authentication public key common to a plurality of authentication servers that perform FIDO authentication in a key registry when a registration request is received from the authentication device;
an authentication process step of acquiring the common authentication public key from the key registry when receiving an authentication request from the authenticator, and performing FIDO authentication using the common authentication public key;
13. An information processing method comprising: a registration process step of storing an authentication public key common to a plurality of authentication servers performing FIDO authentication in a key registry when a registration request is received from an authenticator;
an authentication process step of acquiring the common authentication public key from the key registry when receiving an authentication request from the authenticator, and performing FIDO authentication using the common authentication public key;
An information processing program characterized by causing a computer to execute the above. An information processing method executed by an information processing device,
a group management step of managing a plurality of authentication servers that perform FIDO authentication as an authentication device in units of authentication server groups;
a transmission step of transmitting 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 a common authentication key pair exists among a plurality of authentication servers belonging to the authentication server group;
a key generating 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 when the common authentication key pair does not exist;
Including,
In the transmitting step,
sending the signed challenge if there is a common authentication key pair;
If the common authentication key pair does not exist, the common authentication public key is transmitted together with the signed challenge. A group management procedure for managing a plurality of authentication servers that perform FIDO authentication as an authenticator in units of authentication server groups;
a transmission step of transmitting 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 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 a plurality of authentication servers belonging to the authentication server group if the common authentication key pair does not exist;
Run the following on your computer:
In the transmission step,
sending the signed challenge if there is a common authentication key pair;
If the common authentication key pair does not exist, the common authentication public key is transmitted together with the signed challenge.

Images