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

What is AI technical title?
AI technical title is built by Patsnap AI team. It summarizes the technical point description of the patent document.
By sharing FIDO public keys among trusted RPs, the system addresses the inefficiency of multiple key registrations, improving authentication convenience and reducing registration efforts.

JP2026002010APending Publication Date: 2026-01-08LY CORP

View PDF 1 Cites 0 Cited by

Patent Information

Application Number: JP2024099669
Authority / Receiving Office: JP · JP
Patent Type: Applications
Current Assignee / Owner
Filing Date: 2024-06-20
Publication Date: 2026-01-08

AI Technical Summary

Technical Problem

Conventional FIDO authentication systems require multiple registrations of authentication keys for different Relying Parties (RPs), which is inefficient and inconvenient, even with the use of passkeys.

Method used

An information processing device and method that allows sharing of FIDO public keys between multiple RPs through mutual communication and trust establishment, reducing the need for individual key registrations by enabling key sharing among trusted RPs.

Benefits of technology

Reduces the number of times FIDO authentication keys need to be registered across multiple RPs, enhancing convenience and efficiency in authentication processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

Figure 2026002010000001_ABST

Patent Text Reader

Abstract

To reduce the number of times of registration of a key for authentication of FIDO to a plurality of RPs.SOLUTION: An information processing apparatus according to the present application is an information processing apparatus that serves as an authenticator of FIDO, and includes an authentication processing unit that authenticates an authenticatee by using a FIDO public key corresponding to a FIDO secret key used by the authenticatee, a sharing unit that shares the FIDO public key, which is in principle not open to anyone other than the authenticator for which key registration of FIDO has been performed, with another authenticator satisfying a predetermined condition, and a setting unit that performs setting for performing authentication by using the FIDO public key with the other authenticator on an authenticator of the authenticatee.SELECTED DRAWING: Figure 3

Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

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

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

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

[0004] However, the above-described conventional technology cannot reduce the number of times that FIDO authentication keys are registered for multiple RPs (Relying Parties).

[0005] The present application has been made in consideration of the above, and aims to reduce the number of times FIDO authentication keys are registered for multiple RPs. [Means for solving the problem]

[0006] The information processing device of the present application is an information processing device that serves as a FIDO authenticator, and is characterized by comprising: an authentication processing unit that authenticates the person to be authenticated using a FIDO public key corresponding to a FIDO private key used by the person to be authenticated; a sharing unit that shares the FIDO public key, which is generally not disclosed to anyone other than the authenticator for which FIDO key registration has been performed, with other authenticators that meet specified conditions; and a setting unit that configures the authenticator of the person to be authenticated to perform authentication with the other authenticators using the FIDO public key. [Effects of the Invention]

[0007] According to one aspect of the embodiment, the number of times FIDO authentication keys are registered for multiple RPs can be reduced. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of the FIDO authentication system. [Figure 2] FIG. 2 is an explanatory diagram showing an overview of a FIDO authentication system using a passkey. [Figure 3] FIG. 3 is an explanatory diagram illustrating an overview of an information processing system according to an embodiment. [Figure 4] FIG. 4 is an explanatory diagram showing an overview of an example of group management on the RP side. [Figure 5] FIG. 5 is an explanatory diagram showing an overview of an example of group management on the authentication device side. [Figure 6] FIG. 6 is a diagram illustrating an example of the configuration of a terminal device according to the embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of the configuration of a server device according to the embodiment. [Figure 8] FIG. 8 is a flowchart showing a processing procedure according to the embodiment. [Figure 9] FIG. 9 is a diagram illustrating an example of a hardware configuration. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0011] 1, the FIDO authentication system 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, either wired or wirelessly, so as to be able to communicate with each other. This allows the terminal device 10 to cooperate with the server device 100. The network may be, for example, a local area network (LAN), a wide area network (WAN), the Internet, or the like.

[0012] The terminal device 10 is a smart device such as a smartphone or tablet used by a user U, and is a portable terminal device capable of communicating with any server device via a wireless communication network such as LTE (Long Term Evolution), 4G (4th Generation), or 5G (5th Generation: fifth generation mobile communication system), Bluetooth (registered trademark), or wireless LAN. The terminal device 10 also has a screen such as a liquid crystal display with a touch panel function, and accepts various operations on displayed data such as content, such as tapping, sliding, and scrolling, performed by the user U with a finger or a stylus. Note that an operation performed on an area of the screen where the content is displayed may be considered an operation on the content.

[0013] The terminal device 10 may be not only a smart device but also a desktop or notebook (laptop) type PC (Personal Computer), a feature phone (Gala-ke or Gala-ho) or other mobile phone, a PDA (Personal Digital Assistant), a game console or AV device with a communication function, an information appliance or digital appliance, a car navigation system, a smart watch, a head-mounted display, a wearable device such as 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).

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

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

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

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

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

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

[0020] 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's 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 verify their identity locally. The authenticator then signs the verification result with a private key and sends it to the authentication server as a signed response. Upon receiving the signed response, the authentication server verifies the signature with a public key. The pair of private and public keys is called a key pair.

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

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

[0023] For simplicity of explanation, hereinafter, the RP / IdP and the linked RP / SP are not distinguished from each other, and the server device 100 is described as both an RP / IdP and a linked RP / SP. Note that in practice, the server device serving as the RP / IdP and the server device serving as the linked RP / SP may be physically separate and different server devices.

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

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

[0026] The server device 100 can acquire user information about the user. For example, the server device 100 acquires, as the user information, information about the user's attributes (attribute information), such as the user's gender, age, and residential area. The server device 100 can also acquire information about the user's attributes, such as demographic attributes, psychographic attributes, geographic attributes, and behavioral attributes. The server device 100 may also acquire, as the user information, a segment to which the user belongs in the field of marketing, a persona (personality), and the like. The server device 100 then stores and manages the information about the user's attributes (attribute information) together with identification information (user ID, etc.) that identifies the user.

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

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

[0029] [2. Sharing public keys between RPs] In recent years, FIDO authentication systems have been improving convenience by using passkeys. Figure 2 is an explanatory diagram showing an overview of a FIDO authentication system using passkeys. As shown in Figure 2, if a passkey is adopted, even if a user has multiple devices, a private key created on one device can be shared with other devices. This eliminates the need to register an authentication key pair for each device of the same user with the same RP (Relying Party), thereby reducing the number of registrations.

[0030] However, since FIDO authentication key generation is tied to the origin (generally the internet domain of the service), if there are n RPs (Relying Parties), registration must be performed n times. As such, the use of passkeys does not reduce the number of registrations to different RPs. In other words, passkeys alone do not reduce the effort required to register to multiple RPs.

[0031] Furthermore, even though the FIDO public key (authentication key) held by an RP is a "public key," it is used by the RP for user authentication and therefore should not be unconditionally made public, distributed, or shared with other RPs.

[0032] Even the same business operator may be forced to change the origin due to certain circumstances. In addition, in the case of group companies, trust may be established between RPs, but the origins may be different. Or, in the case of related services, users may trust both RPs equally, but the origins may be different. In the FIDO specification, different origins are treated as different RPs.

[0033] This embodiment provides a means for multiple RPs to share a public key. Specifically, the concept of a passkey is applied to public keys, allowing multiple RPs to share public keys in an appropriate manner. For example, a public key for authentication is shared through mutual communication between RPs. This is an extended function in the FIDO specifications. Alternatively, a password manager has a function that can pass a password for an arbitrary server to another server, so this function can be used to pass a public key for an arbitrary server to another server.

[0034] [2-1. Same operator, different origins] An overview of the information processing system according to the embodiment will be described with reference to Fig. 3. Fig. 3 is an explanatory diagram showing an overview of the information processing system according to the embodiment. Note that Fig. 3 describes a case where the same business operator has different origins.

[0035] As shown in FIG. 3, an information processing system 1 according to an embodiment includes a terminal device 10 of a user (authenticated party) that serves as an authenticator (and a FIDO client) in FIDO, and a server device 100 that serves as an RP (Relying Party) in FIDO. In FIG. 3, as an example, the server device 100 includes a server device 100A that serves as a FIDO server A (authenticator) and a server device 100B that serves as a FIDO server B (another authenticator). FIDO server A is a FIDO server to which a user has registered a key. FIDO server B is a FIDO server to which a user has not registered a key (unregistered). FIDO server A and FIDO server B are server devices managed by the same operator but have different origins. In other words, they are server devices in which trust is established between the RPs.

[0036] For example, as shown in Fig. 3, a server device 100A, which is a FIDO server A having a FIDO key pair set therein, performs FIDO authentication on a user (step S1). The FIDO authentication is performed in accordance with the normal FIDO specifications.

[0037] Next, if the server device 100A, which is FIDO server A, successfully authenticates the user through FIDO, it confirms with the user whether they consent to the sharing of the public key with FIDO server B, which has established trust between the RPs (step S2).

[0038] Next, when permission is received from the user, server device 100A, which is FIDO server A, transfers the public key or notifies server device 100B, which is FIDO server B, of the reference destination of the public key (step S3). For example, based on the user's consent, FIDO server A physically transfers the public key to FIDO server B or enables FIDO server B to refer to the same DB (database) in which the public key is stored. At this time, FIDO server A may perform access control (change settings) to allow FIDO server B to refer to the public key.

[0039] Next, the server device 100A, which is FIDO server A, configures the terminal device 10, which is the user's authenticator, to allow the same key to be used even when the origins are different (step S4). This is an extension function that differs from the FIDO specifications. For example, the FIDO server A configures the authenticator's FIDO authentication information to allow the same key to be used for multiple origins. Alternatively, the FIDO server A requests the authenticator to change only the origin and replicate the FIDO authentication information. Note that, in practice, the authenticator may receive a notification from the FIDO server A that the FIDO public key has been shared with the FIDO server B and configure the authenticator to allow the same key to be used even when the origins are different.

[0040] Next, the server device 100B, which is the FIDO server B, performs FIDO authentication on the user using the transferred or notified public key (step S5).

[0041] Next, if the FIDO authentication of the user is successful, the server device 100B, which is the FIDO server B, provides a service to the user (step S6).

[0042] In this way, in this embodiment, by sharing the public key corresponding to the passkey, the number of registrations can be further reduced compared to when only the passkey is used.

[0043] Note that the above only describes server device 100B, which is FIDO server B, but it is also possible to share public keys with FIDO servers other than FIDO server B (other FIDO servers that have been trusted) using the same procedure as above.

[0044] In addition, when FIDO Server A receives a request from FIDO Server B to share (publish) a user's FIDO public key, it may confirm with the user whether they agree to share the public key with FIDO Server B.

[0045] [2-2. Group management on the RP side] An example of group management on the RP side will be described with reference to Fig. 4. Fig. 4 is an explanatory diagram showing an overview of an example of group management on the RP side.

[0046] For example, as shown in Fig. 4, the server device 100A, which is a FIDO server A in which a FIDO key pair is set, performs FIDO authentication on the user (step S11). The FIDO authentication is performed in accordance with the normal FIDO specifications.

[0047] Next, if the FIDO authentication of the user is successful, the server device 100A, which is FIDO server A, presents to the user via a UI (user interface) a list of FIDO servers (candidates) for key sharing (RP trust list) and confirms permission to share the public key with each of the FIDO servers on the list (step S12). The list of FIDO servers (RP trust list) is assumed to be stored by the server device 100A, which is FIDO server A. Here, it is assumed that permission to share the public key with FIDO server C (another authenticator) has been granted in addition to FIDO server A (authenticator) that already stores and uses the public key.

[0048] Next, the server device 100A, which is the FIDO server A, transfers the public key or notifies the server device 100C, which is the FIDO server C, which has received permission from the user (step S13).

[0049] Next, the server device 100A, which is the FIDO server A, configures the terminal device 10, which is the authenticator of the user, so that the same key can be used even on a FIDO server C with a different origin (step S14). Note that, in practice, the authenticator may receive a notification from the FIDO server A that a key has been shared with the FIDO server C, and configure the authenticator so that the same key can be used even on a FIDO server C with a different origin.

[0050] Next, the server device 100C, which is the FIDO server C, performs FIDO authentication on the user using the transferred or notified public key (step S15).

[0051] Next, if the FIDO authentication of the user is successful, the server device 100C, which is the FIDO server C, provides the service to the user (step S16).

[0052] In practice, each FIDO server belonging to the same corporate group may have a list of FIDO servers belonging to the same group company in advance. If they are part of the same group company, it can be said that trust is established between the RPs. Then, when a user logs in to one of the FIDO servers belonging to the same corporate group using FIDO authentication, the list of FIDO servers belonging to the group company may be presented, and permission to share the public key with each FIDO server on the list may be confirmed.

[0053] [2-3. Group management on the authentication device side] An example of group management on the authentication device side will be described with reference to Fig. 5. Fig. 5 is an explanatory diagram showing an overview of an example of group management on the authentication device side.

[0054] For example, as shown in Fig. 5, the server device 100A, which is a FIDO server A in which a FIDO key pair is set, performs FIDO authentication on the user (step S21). The FIDO authentication is performed in accordance with the normal FIDO specifications.

[0055] Next, the terminal device 10 serving as the user's authenticator provides the server device 100A serving as FIDO server A with a list (user permission list) of FIDO servers trusted by the user that are authorized to share the public key, and requests each of the FIDO servers on the list to share the public key (step S22). The list of FIDO servers (user permission list) is assumed to be stored in the terminal device 10 serving as the user's authenticator. Here, it is assumed that the terminal device 10 has authorized FIDO server C to share the public key, separate from FIDO server A, which already stores and uses the public key.

[0056] Next, the server device 100A, which is FIDO server A, transfers the public key or notifies the reference destination of the public key to the server device 100C, which is FIDO server C, with which the user has authorized key sharing (step S23). At this time, the FIDO server A may determine whether the FIDO server C is a trusted RP according to its own determination criteria. Then, only if the FIDO server C is a trusted RP, the FIDO server A may transfer the public key or notify the reference destination of the public key to the FIDO server C. In addition, in response to the request for public key sharing, the FIDO server A may return a response to the user indicating that the public key has been shared with the server device 100C. Note that if the FIDO server C is not a trusted RP, the FIDO server A may return a response to the user indicating that the public key has been shared with the FIDO server C, together with the reason for the denial, and terminate the series of processes.

[0057] Next, the terminal device 10, which is the authenticator of the user, receives a notification from the server device 100A, which is FIDO server A, that the key has been shared with the FIDO server C, and configures the terminal device 10 so that the same key can be used even for the FIDO server C with a different origin (step S24). Note that in practice, the FIDO server A may configure the authenticator so that the same key can be used even for the FIDO server C with a different origin.

[0058] Next, the server device 100C, which is the FIDO server C, performs FIDO authentication on the user using the transferred or notified public key (step S25).

[0059] Next, if the FIDO authentication of the user is successful, the server device 100C, which is the FIDO server C, provides the service to the user (step S26).

[0060] In practice, FIDO Server A may request a list (user authorization list) of FIDO servers that the user trusts and that are authorized to share the public key from the user's authenticator. Then, in response to the list request from FIDO Server A, the user's authenticator may provide FIDO Server A with a list of FIDO servers that the user trusts and that are authorized to share the public key.

[0061] In addition, when FIDO Server A receives a disclosure request (sharing request) from a user or FIDO Server C for a FIDO public key corresponding to a FIDO private key used to authenticate a user, FIDO Server A may disclose the FIDO public key to FIDO Server C. Note that disclosure of the FIDO public key requires the user's consent. Then, FIDO Server C authenticates the user using the FIDO public key corresponding to the FIDO private key used by the user.

[0062] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of the configuration of the terminal device 10 according to the embodiment. As shown in Fig. 6, 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.

[0063] (Communications Department 11) The communication unit 11 is connected to a network via a wired or wireless connection, and transmits and receives information to and from the server device 100 via the network. For example, the communication unit 11 is realized by a NIC (Network Interface Card), an antenna, or the like.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0081] (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.

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

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

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

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

[0086] (Communication unit 110) The communication unit 110 is realized by, for example, a network interface card (NIC), etc. The communication unit 110 is connected to a network via a wired or wireless connection.

[0087] (Storage unit 120) The storage unit 120 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD, an SSD, an optical disk, etc. The storage unit 120 may store attribute information and history information (log data) of the user U together with identification information (such as a user ID) indicating the user U.

[0088] (control unit 130) The control unit 130 is a controller, and is realized by, for example, a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like, by 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. 7, the control unit 130 has an acquisition unit 131, a management unit 132, an authentication processing unit 133, a reception unit 134, a confirmation unit 135, a sharing unit 136, and a setting unit 137.

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

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

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

[0092] In addition, the acquisition unit 131 acquires, from the subject to be authenticated, a list of other authenticators (other FIDO servers) that the subject to be authenticated, user U (user), trusts and authorizes sharing of the FIDO public key. For example, the acquisition unit 131 acquires, via the communication unit 110, from the terminal device 10 of the user U, which is the authenticator of the subject to be authenticated, a list of other authenticators held by the terminal device 10.

[0093] (Management Department 132) The management unit 132 manages a list of other authenticators with which the FIDO public key is shared. For example, the management unit 132 manages a list of other authenticators that are group companies or the like and that have established trust with the server device 100, which is the authenticator. The management unit 132 may also manage a list of other authenticators acquired from the terminal device 10 of the user U, who is the authenticator of the person to be authenticated. The management unit 132 may also manage the FIDO public key in cooperation with the storage unit 120.

[0094] (Authentication processing unit 133) The authentication processing unit 133 authenticates a user U (a person to be authenticated) by using a FIDO public key corresponding to a FIDO private key used by the user U. That is, the authentication processing unit 133 performs authentication by FIDO.

[0095] (Reception Department 134) The reception unit 134 receives a request from an authenticatee or another authenticator to share a FIDO public key between the authenticator (an authenticator having a FIDO public key) and another authenticator (an authenticator not having the FIDO public key). Note that the reception unit 134 may be common to the acquisition unit 131.

[0096] (Verification Section 135) Before sharing the FIDO public key with another authenticator, the confirmation unit 135 inquires of the person to be authenticated to confirm whether or not the person agrees to the sharing of the FIDO public key between the authenticator and the other authenticator. For example, the confirmation unit 135 inquires of the terminal device 10 of the user U, which is the authenticator of the person to be authenticated, via the communication unit 110 to confirm whether or not the person agrees to the sharing of the FIDO public key between the authenticator and the other authenticator.

[0097] (Shared part 136) The sharing unit 136 shares the FIDO public key, which is generally not disclosed to anyone other than the verifier for which the FIDO key has been registered, with other verifiers that satisfy certain conditions. Note that other verifiers that satisfy certain conditions are other verifiers that at least the verifier having the FIDO public key has determined to be trustworthy. For example, other verifiers that belong to the same corporate group as the verifier, other verifiers that have established trust with the verifier, other verifiers that have established trust with the person to be authenticated, etc. Note that the conditions for determining whether to trust other verifiers can be arbitrarily set by the verifier having the FIDO public key.

[0098] For example, the sharing unit 136 provides (physically transfers) the FIDO public key to other authenticators. Alternatively, the sharing unit 136 notifies other authenticators of the location (reference) of the FIDO public key. Alternatively, the sharing unit 136 stores the FIDO public key in a predetermined storage location and makes it public to other authenticators, allowing the other authenticators to access the FIDO public key.

[0099] In addition, the sharing unit 136 shares the FIDO public key with other verifiers when the person to be authenticated agrees to the sharing of the FIDO public key between the verifier and other verifiers.

[0100] In addition, when the sharing unit 136 receives a request from the person to be authenticated or another authenticator to share a FIDO public key between the authenticator and the other authenticator, the sharing unit 136 shares the FIDO public key with the other authenticator.

[0101] (Settings section 137) The setting unit 137 performs settings on the authenticator of the person to be authenticated so that authentication can be performed between the authenticator and another authenticator using a FIDO public key. For example, the setting unit 137 performs settings on the terminal device 10 of the user U, which is the authenticator of the person to be authenticated, via the communication unit 110 so that the same key can be used even if the origins are different.

[0102] [5. Processing Procedure] Next, a processing procedure by the server device 100 according to the embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart showing the 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.

[0103] For example, as shown in FIG. 8, the authentication processing unit 133 of the server device 100, which serves as the FIDO authenticator, communicates with the terminal device 10 of the user U, which serves as the authenticator of the person to be authenticated, via the communication unit 110, and authenticates the person to be authenticated using the FIDO public key corresponding to the FIDO private key used by the user U, who is the person to be authenticated (step S101).

[0104] Furthermore, the sharing unit 136 of the server device 100 checks whether the receiving unit 134 has received a request for sharing a FIDO public key between the authenticator and the other authenticator from the person to be authenticated or another authenticator via the communication unit 110 (step S102). If a request for sharing a FIDO public key has been received (step S102; Yes), the processing proceeds to step S105. Conversely, if a request for sharing a FIDO public key has not been received (step S102; No), the processing proceeds to step S103.

[0105] Furthermore, the sharing unit 136 of the server device 100 checks whether the authenticator desires to share the FIDO public key with other authenticators (step S103). If the authenticator desires to share the FIDO public key with other authenticators (step S103; Yes), the process proceeds to step S104. Conversely, if the authenticator does not desire to share the FIDO public key with other authenticators (step S103; No), the process proceeds to step S106.

[0106] Next, the confirmation unit 135 of the server device 100 refers to a list of other authenticators with which the FIDO public key is to be shared, which is a list stored by the management unit 132 (step S104).

[0107] Next, the confirmation unit 135 of the server device 100 inquires of the terminal device 10 of the user U, which serves as the authenticator of the person to be authenticated, via the communication unit 110 to confirm whether the person to be authenticated agrees to the sharing of a FIDO public key between the authenticator and other authenticators (step S105). At this time, the confirmation unit 135 may present the terminal device 10 of the user U, which serves as the authenticator of the person to be authenticated, with a list of other authenticators stored by the management unit 132 (or other authenticators listed on the list) to confirm whether the person to be authenticated agrees to key sharing with each of the other authenticators. If the person to be authenticated agrees to the sharing of a FIDO public key between the authenticator and other authenticators (step S105; Yes), the process proceeds to step S108. Conversely, if the person to be authenticated does not agree to the sharing of a FIDO public key between the authenticator and other authenticators (step S105; No), the process ends without doing anything.

[0108] Alternatively, the sharing unit 136 of the server device 100 checks whether the acquiring unit 131 has acquired a list of other authenticators that the user U (user), who is the subject to authentication, trusts and authorizes sharing of the FIDO public key from the terminal device 10 of the user U, which serves as the authenticator of the subject to authentication, via the communication unit 110 (step S106). If the list of other authenticators has been acquired from the terminal device 10 of the user U (step S106; Yes), the sharing unit 136 refers to the acquired list of other authenticators (step S107). Note that if the list of other authenticators has been acquired from the subject to authentication, it is determined that the subject to authentication has consented to key sharing with the other authenticators listed on the list. Conversely, if the list of other authenticators has not been acquired from the terminal device 10 of the user U (step S106; No), the sharing unit 136 does nothing and ends the series of processes.

[0109] Next, the sharing unit 136 of the server device 100 shares the FIDO public key, which is generally not disclosed to anyone other than the authenticator for whom the FIDO key has been registered, with other trusted authenticators who have been granted permission to share the key based on the list of other authenticators (step S108).

[0110] Next, the setting unit 137 of the server device 100 configures the terminal device 10 of the user U, which will be the authenticator of the person to be authenticated, via the communication unit 110 to perform authentication with other authenticators using a FIDO public key (step S109).

[0111] This allows other authenticators to use the FIDO public key to configure the authenticatee.

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

[0113] 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 (or an application running on the terminal device 10). For example, the processing may be completed in a stand-alone manner (by the terminal device 10 alone). There is also a technology in which the terminal device 10 performs authentication with another authenticator on behalf of the FIDO server and notifies the FIDO server of the authentication result. In this case, it is assumed that the terminal device 10 has the functions of the server device 100 in the above embodiment. Furthermore, in the above embodiment, since the terminal device 10 cooperates with 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 be said that the terminal device 10 includes the server device 100.

[0114] In the above embodiment, a list of other authenticators (other FIDO servers) that have established trust with the authenticator or the authenticatee may be stored in a database or server on the network, and the authenticator may obtain the list of other authenticators from the network as needed.

[0115] In addition, in the above embodiment, an authenticator (FIDO server) that shared a FIDO public key with another authenticator may also share the FIDO public key held by the other authenticator. In other words, FIDO servers that have established mutual trust may share the FIDO public keys that they currently hold with each other.

[0116] Furthermore, in the above embodiment, the terminal device 10 of the user U (user), which serves as the authenticator of the person to be authenticated, may be configured, by an app function or the like, to enable the use of the same key even when the origins are different, when the user U agrees to the sharing of the FIDO public key between the authenticator and another authenticator. For example, when the user U agrees to the sharing of the FIDO public key between the authenticator and another authenticator, the terminal device 10 of the user U may use this as a trigger to change the FIDO authentication information so that authentication is performed between the person to be authenticated and another authenticator using the same authentication key pair as between the person to be authenticated and the authenticator.

[0117] [7. Effects] As described above, the information processing device (terminal device 10 and server device 100) of the present application is an information processing device that serves as a FIDO authenticator, and is characterized by comprising: an authentication processing unit 133 that authenticates the person to be authenticated (user) using a FIDO public key corresponding to the FIDO private key used by the person to be authenticated; a sharing unit 136 that shares the FIDO public key, which is generally not disclosed to anyone other than the authenticator for which FIDO key registration has been performed, with other authenticators that satisfy specified conditions; and a setting unit 137 that sets up the authenticator of the person to be authenticated to perform authentication with other authenticators using the FIDO public key.

[0118] The sharing unit 136 provides the FIDO public key to other authenticators.

[0119] Alternatively, the sharing unit 136 notifies other authenticators of the location of the FIDO public key.

[0120] Alternatively, the sharing unit 136 stores the FIDO public key in a predetermined storage location and makes it available to other authenticators, allowing the other authenticators to access the FIDO public key.

[0121] In addition, the information processing device according to the present application further includes a confirmation unit 135 that, before sharing the FIDO public key with another authenticator, inquires of the person to be authenticated to confirm whether or not the person to be authenticated agrees to the sharing of the FIDO public key between the authenticator and the other authenticator. The sharing unit 136 shares the FIDO public key with the other authenticator when the person to be authenticated agrees to the sharing of the FIDO public key between the authenticator and the other authenticator.

[0122] The information processing device according to the present application further includes a receiving unit 134 that receives a request from the person to be authenticated or another authenticator to share a FIDO public key between the authenticator and the other authenticator. When the sharing unit 136 receives a request from the person to be authenticated or another authenticator to share a FIDO public key between the authenticator and the other authenticator, the sharing unit 136 shares the FIDO public key with the other authenticator.

[0123] In addition, the information processing device according to the present application further includes a management unit 132 that manages a list of other authenticators with which the FIDO public key is shared.

[0124] In addition, the information processing device according to the present application further includes an acquisition unit that acquires, from the person to be authenticated, a list of other authenticators that the person to be authenticated trusts and with whom the person to be authenticated is authorized to share the FIDO public key.

[0125] By using any one or a combination of the above-described processes, the information processing device according to the present application can reduce the number of times FIDO authentication keys are registered for multiple RPs.

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

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

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

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

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

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

[0132] 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.

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

[0134] 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.

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

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

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

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

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

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

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

[0142] 1. Information Processing Systems 10 Terminal Equipment 100 Server device 110 Communications Department 120 Storage section 130 Control Unit 131 Acquisition Department 132 Management Department 133 Authentication processing section 134 Reception Department 135 Verification Department 136 Common area 137 Setting section

Claims

1. An information processing device that serves as a FIDO certifier, an authentication processing unit that authenticates the person to be authenticated using a FIDO public key corresponding to a FIDO private key used by the person to be authenticated; A sharing unit that shares the FIDO public key, which is generally not disclosed to anyone other than the certifier who has registered the FIDO key, with other certifiers who meet certain conditions; a setting unit that sets the authenticator of the person to be authenticated to perform authentication with the other authenticator using the FIDO public key; An information processing device comprising:

2. The sharing unit provides the FIDO public key to the other authenticator.