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

Abstract

To provide an information processing device, an information processing method, and an information processing program that are capable of appropriately managing secret keys.SOLUTION: An information processing device includes a control unit that obtains a plurality of secret keys each of which is registered in each of a plurality of authenticators that are used by an identical user; and aggregates the obtained plurality of secret keys for each combination of an authentication object and a user account for the authentication object.SELECTED DRAWING: Figure 2

Description

[Technical field]

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

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

[0003] [Patent Document 1] JP 2020-141331 A Summary of the Invention [Problem to be solved by the invention]

[0004] However, the conventional technology has room for further improvement in terms of proper management of the private key, which is one of the key pair.

[0005] The present application has been made in consideration of the above, and has an object to provide an information processing device, an information processing method, and an information processing program that are capable of appropriately managing private keys. [Means for solving the problem]

[0006] The information processing device of the present application is equipped with a control unit that acquires multiple private keys registered in multiple authentication devices used by the same user, and consolidates the acquired multiple private keys for each combination of an authentication subject and the user's account in the authentication subject. Effect of the Invention

[0007] According to one aspect of the embodiment, an effect is achieved in that private keys can be appropriately managed. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1A is a diagram showing a process executed in an authentication system according to an embodiment. [Figure 1B] FIG. 1B is a diagram showing a process executed in the authentication system according to the embodiment. [Figure 1C] FIG. 1C is a diagram showing a process executed in the authentication system according to the embodiment. [Figure 1D] FIG. 1D is a diagram showing a process executed in the authentication system according to the embodiment. [Figure 1E] FIG. 1E is a diagram illustrating a private key capsule. [Figure 1F] FIG. 1F is a diagram showing a process executed in the authentication system according to the embodiment. [Figure 1G] FIG. 1G is a diagram showing a process executed in the authentication system according to the embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of the configuration of an authentication server according to the embodiment. [Diagram 3] FIG. 3 is a diagram illustrating an example of user information. [Figure 4] FIG. 4 is a diagram illustrating an example of public key information. [Diagram 5] FIG. 5 is a diagram illustrating an example of the authentication control policy information. [Figure 6] FIG. 6 is a diagram illustrating an example of the configuration of an authentication device according to the embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of the private key capsule information. [Figure 8] FIG. 8 is a diagram illustrating an example of the deployment policy information. [Figure 9] FIG. 9 is a diagram illustrating an example of a hardware configuration. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, the information processing device, the information processing method, and the information processing program according to the present application 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 the embodiments. In addition, the same parts in the following embodiments are denoted by the same reference numerals, and duplicated descriptions are omitted.

[0010] (Embodiment) First, the processing executed in the authentication system according to the embodiment will be described with reference to Fig. 1A to Fig. 1D. Fig. 1A to Fig. 1D are diagrams showing the processing executed in the authentication system according to the embodiment. Fig. 1A to Fig. 1D show a configuration example and processing example of the authentication system S.

[0011] The authentication process described below uses an authentication technology called FIDO (Fast Identity Online: registered trademark) as an authentication technology when a user uses various services on the Internet. In FIDO authentication, the identity of a user is verified by an authentication device built into or attached to a user device such as a smartphone. An example of an authentication device is the biometric authentication function of a smartphone. In this way, FIDO authentication employs local authentication. Note that, although FIDO authentication is taken up in the present invention as one implementation form of authentication based on public key cryptography, the present invention is not limited to FIDO authentication and can be widely applied to authentication methods using public key cryptography.

[0012] In local authentication, the authenticator digitally signs the result of the authentication by using a private key stored in the authenticator. The result of the authentication with the digital signature is then sent from the user device to an authentication server on the Internet. The authentication server on the Internet can verify the validity of the result of the authentication with the digital signature sent from the user device by using a public key registered in the authentication server.

[0013] As described above, FIDO authentication enables passwordless authentication using an authenticator built into or external to a user device. For example, a user can perform passwordless login to a service that employs FIDO authentication by inputting biometric information such as a fingerprint into a smartphone. Since FIDO authentication enables a user to log in to a service without using a password, FIDO authentication is preferable from the standpoints of convenience and security.

[0014] As described above, in local authentication, the generated private key does not leave the authenticator that generated it, and conversely, private keys generated by other authenticators do not enter it. On the other hand, in terminal devices such as smartphones, terminals are frequently replaced and there are users who own multiple devices. For this reason, in FIDO authentication, it is being considered to make it possible to use private keys in authenticators other than the one that generated them.

[0015] On the other hand, when a private key is shared among multiple authentication devices, there is a risk that distributing the private key to another user's authentication device may allow the other user to impersonate the other user and log in to the service, and distributing a private key that can log in to a phishing site to a user may allow the user to unintentionally log in to the phishing site. Thus, there is still room for improvement in the provision and storage of personal privacy information.

[0016] Therefore, in this disclosure, a technique is proposed for preventing the above-mentioned spoofing and unintentional login to a phishing site. An authentication system S that executes the authentication process in this disclosure will be described below with reference to Figs. 1A to 1D.

[0017] First, the process of generating a private key and registering it in the authentication server 1 will be described with reference to FIG. 1A.

[0018] As shown in FIG. 1A, an authentication system S according to the embodiment includes an authentication server 1 and an authentication device 100.

[0019] The authentication server 1 is an information processing device that works in conjunction with each user's terminal device (authentication device 100) and provides each user's terminal device with API (Application Programming Interface) services for various applications (hereinafter, apps), etc., as well as various data, and is realized by a computer, a cloud system, etc.

[0020] The authentication server 1 also has a user authentication function and a user information management function. The authentication server 1 uses the user information management function to manage, as a data capsule, meta-information of data managed by the data management function of the user's terminal device. The authentication server 1 then uses the user authentication function to authenticate the user using the meta-information managed as a data capsule.

[0021] The authentication server 1 may also be an information processing device that provides some kind of online Web service to each user's terminal device. For example, the authentication server 1 may provide services such as 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 as Web services. In practice, the authentication server 1 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.

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

[0023] The authenticator 100 is a smart device such as a smartphone or tablet terminal used by a user, and is a mobile terminal device that can communicate with any server device via a wireless communication network such as 5G (Generation) or LTE (Long Term Evolution). The authenticator 100 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, scrolling, etc., performed by a user's finger or a stylus. An operation performed on an area of ​​the screen where the content is displayed may be considered to be an operation on the content. The terminal device may be not only a smart device, but also an information processing device such as a desktop PC (Personal Computer) or a notebook PC.

[0024] Moreover, the authenticator 100 has a data management function. The authenticator 100 stores information (data) relating to an individual user in a safe place. The safe place may be a secure area (secure element) inside the authenticator 100, or may be an external storage device. If the safe place is an external storage device, the authenticator 100 may have an appropriate access control function for safely accessing the external storage device. Moreover, the data stored inside the authenticator 100 may itself be link information to an external device. The external storage device may be a USB key, a My Number card, or the like, or may be a storage server, etc. Moreover, the link information to the external device may be ledger information in blockchain technology (distributed ledger technology).

[0025] For example, the authenticator 100 may store various information related to the user. Specifically, the authenticator 100 may store information related to attributes such as the user's demographic (demographic attributes), psychographic (psychological attributes), geographic (geographic attributes), behavioral (behavioral attributes), etc. For example, the authenticator 100 may store information such as name, age, sex, address (home), place of work, family structure, place of origin (local area), occupation, position, income, qualifications, type of residence (detached house, apartment, etc.), presence or absence of 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 zone, etc.), hobbies, interests, lifestyle, etc.

[0026] As shown in FIG. 1A, first, the authenticator 100 accepts a registration request for a service from a user (step S1). Next, the authenticator 100 transmits an authentication request to the authentication server 1 (step S2). Next, the authentication server 1 generates an authentication request message based on the received authentication request (step S3). Next, the authentication server 1 transmits an authentication request (challenge) to the authenticator 100 (step S4).

[0027] Next, the authentication device 100 requests the user to input biometric information in accordance with the authentication request message (step S5), and accepts the biometric information from the user (step S6).

[0028] Next, the authenticator 100 creates a private key management environment, creates a key pair of a private key and a public key thereon, and stores the context information of the private key (information about the environment in which the private key was generated and information about the private key use target). Next, an attestation (including the above-mentioned public key and private key management environment identifier, and signed with the private key for attestation) is created, and further, private key capsule information (described later in FIG. 1E) is generated (step S7). Specifically, the private key capsule information is the context information of the private key plus information about the distribution target of the private key. The private management environment is information identified by an identifier so as to be unique on the Internet, and may be information that is uniquely issued by a combination of a user, the authenticator 100, and an authentication target (such as a domain) that provides a service. Alternatively, the private key management environment identifier may be a combination of the identifier of the authenticator 100 and a random character string. Alternatively, the private key management environment identifier may be a combination of the identifier of the authenticator 100 and a character string representing the name of the private key management environment. In the following, the private key management environment is referred to as a base, and the private key management environment identifier is referred to as a base ID. Next, the authenticator 100 transmits an authentication response including an attestation including the base ID to the authentication server 1 (step S8).

[0029] The authentication server 1 verifies the received attestation, and if the verification is successful, registers the public key and base ID included in the attestation to itself (step S9). Specifically, the authentication server 1 identifies a public key for the attestation based on the attestation, and verifies the signature of the private key in the attestation using the identified public key. Furthermore, if the attestation verification confirms the certification of the authenticator 100, the authentication server 1 registers the public key linked to the user ID and base ID to itself.

[0030] If the authentication server 1 is able to confirm the certification of the authentication device 100 as a result of the attestation verification, it notifies the authentication server 1 of an authentication result indicating that the certification of the authentication device 100 has been successful, and if the certification of the authentication device 100 cannot be confirmed, it notifies the authentication server 1 of an authentication result indicating that the authentication has failed (step S10).

[0031] As described above, through steps S1 to S10 shown in FIG. 1A, a private key linked to the base ID is registered in authentication device 100, and a public key linked to the base ID is registered in authentication server 1.

[0032] Next, a deployment control process in which a private key is shared among a plurality of authenticators 100 will be described with reference to Fig. 1B. Fig. 1B illustrates an example in which a private key generated in a first authenticator 100a is shared with a second authenticator 1000b.

[0033] As shown in FIG. 1B, the user sets the OS (Operating System) and the like so that the second authenticator 100b can be used (step S1). Next, the user sets a private key deployment policy and a public key for private key capsule for the second authenticator 100b (step S2). The private key deployment policy is a policy for accepting (deploying) a private key from the first authenticator 100a, and is, for example, a policy in which a base ID of an acceptable authenticator 100 (i.e., the base ID of the first authenticator 100a) is set. The public key for private key capsule may be acquired by the second authenticator 100b while being stored in an external server (an authenticator vendor's server or a public repository server), or may be directly transmitted from the first authenticator 100a to the second authenticator 100b if the first authenticator 100a is reliable.

[0034] Next, the first authenticator 100a makes a request to the user to create a private key capsule (step S3), and receives an operation from the user to authenticate the creation request (step S4). Next, the first authenticator 100a generates a private key capsule (step S5). Details of the private key capsule will be described with reference to FIG. 1E.

[0035] Fig. 1E is a diagram showing a private key capsule. The private key capsule shown in Fig. 1E may be generated, for example, when the private key capsule is sent to the second authenticator 100b. In addition, the private key capsule is not limited to being generated by the authenticator 100, but may be created by the authentication server 1 and obtained from the authentication server 1.

[0036] 1E, the private key capsule includes a private key, context information related to the private key, and a signature. The context information is private key management environment information, and includes information about the environment in which the private key was generated, information about the subject of use of the private key (the subject of authentication), and information about the subject of distribution of the private key.

[0037] The information on the environment in which the private key was generated includes the identifier of the authenticator 100, information on the vendor of the authenticator 100 (vendor name, vendor identifier, etc.), and a base ID (base identifier). The information on the user of the private key (authentication subject) includes the identifier of the authentication server 1 (identifier of the authentication subject) and a user ID registered in the authentication server 1. The information on the distribution subject of the private key includes the base ID to which the private key can be distributed (base ID of another authenticator 100) and information on the authenticator vendor to which the private key can be distributed.

[0038] When the authenticator 100 shares its private key capsule with the second authenticator 100b, it generates a key pair of a private key for the private key capsule and a public key, and signs the private key capsule with the private key for the private key capsule.

[0039] Returning to Fig. 1B, the first authenticator 100a sends the generated private key capsule to the second authenticator 100b (step S6). Next, the second authenticator 100b verifies the private key capsule (step S7). Specifically, the second authenticator 100b identifies a public key for the private key capsule based on the private key capsule, and verifies the private key capsule using the identified public key.

[0040] Next, the second authenticator 100b performs a deployment judgment as to whether or not the private key capsule can be deployed in itself (step S8). Specifically, the second authenticator 100b registers (stores) the private key capsule in itself when the base ID of the private key capsule matches the base ID registered in the deployment policy. In other words, the deployment control of the present disclosure controls so that only the private capsule of the authenticator 100 that is permitted in advance by the deployment policy can be deployed. This makes it possible to refuse acceptance even if a malicious user, such as a spoofer, sends an unauthorized private key capsule.

[0041] Next, when the second authenticator 100b determines that the private key capsule can be deployed, it generates a new private key base (base ID) and deploys it in itself by linking it to the private key (step S9). Specifically, the second authenticator 100b links the base ID of the information on the environment in which the private key was generated in the context information to the base ID corresponding to the second authenticator 100b.

[0042] 1E shows an example in which one private key is included in the private key capsule, but one private key capsule may include multiple private keys. The private key for the private key capsule may be generated at the stage when the private key capsule is generated, or may be generated in advance at the time of manufacturing and shipping the authentication device 100. The private key for the private key capsule may be substituted with a private key for attestation generated to sign the attestation information. The private key capsule may be generated not only by the authentication device 100 but also by the authentication server 1.

[0043] Next, an example of a failure in the deployment control process will be described with reference to Fig. 1C. In Fig. 1C, it is assumed that server 200, which is a malicious site, prepares a script in advance to download a fake private key in an attempt to impersonate a user.

[0044] As shown in Fig. 1C, the user sets the OS (Operating System) etc. so that the second authenticator 100b can be used (step S1). Next, the user sets a deployment policy and a public key for private key capsule for the second authenticator 100b (step S2). Note that in Fig. 1C, it is assumed that only the base ID of the first authenticator 100a shown in Fig. 1B is set in the deployment policy.

[0045] Next, the user performs an operation to request access to a site provided by the server 200 (step S3). In response to this operation, the second authenticator 100b transmits an access request to the server 200 (step S4).

[0046] Next, the server 200 creates a false private key in order to impersonate the user (step S5), and transmits an access response including the false private key to the second authenticator 100b (step S6).

[0047] Next, the second authenticator 100b verifies the false private key (step S7). At this stage, the second authenticator 100b can prevent the deployment of the false private key because the false private key does not match the format of the private key capsule. Furthermore, even if the false private key matches the format of the private key capsule, the second authenticator 100b performs a deployment determination using the deployment policy (step S8). This makes it clear that the false private key is not a private key permitted by the deployment policy, and therefore the deployment of the false private key can be prevented.

[0048] Next, the authentication process at the time of login will be described with reference to Fig. 1D. Note that Fig. 1D assumes that the generation of the private key and the user registration shown in Fig. 1A have been completed. In other words, the authentication device 100 holds a private key linked to a base ID, and the authentication server 1 holds a public key linked to a base ID. Also, it is assumed that the authentication server 1 has set an authentication control policy in advance that "authentication requests from a base identified by a specified base ID will be accepted."

[0049] First, the authentication device 100 accepts a login operation to a service from a user (step S1). Next, when the authentication device 100 accepts a login operation to a service from a user, the authentication device 100 transmits an authentication request for authenticating the login to the service to an authentication server (step S2). The authentication request is transmitted including the above-mentioned base ID.

[0050] Next, the authentication server 1 generates an authentication request message including the base ID of the authentication request based on the authentication request (step S3). Specifically, first, the authentication server 1 refers to the authentication control policy and determines whether or not to accept the authentication request based on the base ID in the authentication request. The authentication server 1 accepts the authentication request when the base ID included in the authentication request matches the base ID linked to the public key registered in the authentication server 1. Furthermore, when the base ID included in the authentication request is unregistered (that is, when an authentication request is made from the second authenticator 100b with which the private key capsule is shared), the authentication server 1 accepts the authentication request when the base ID permitted by a preset authentication control policy matches the base ID included in the authentication request. Furthermore, when the base ID included in the authentication request accepted from the authenticator 100 does not match, the authentication server 1 rejects the authentication request. In other words, when the base ID included in the authentication request does not match either the registered base ID or the base ID permitted by the authentication control policy, the authentication server 1 rejects the authentication request.

[0051] Next, the authentication server 1 transmits the challenge (authentication request) and the base ID together with an authentication request message generated based on the accepted authentication request to the authenticator 100 (step S4). When the authentication server 1 rejects the authentication request in step S3, it notifies the authentication device 100 that the authentication request is rejected instead of performing the process in step S4.

[0052] If the authenticator 100 has multiple base IDs, it checks whether the base ID received together with the challenge exists, and if it does, displays on the screen a message indicating that the request is for access to the service corresponding to that base ID. This allows the user to check the service that he or she is about to access.

[0053] Next, the authentication device 100 requests the user to input biometric information in accordance with the authentication request message (step S5), and accepts the biometric information from the user (step S6).

[0054] Next, the authenticator 100 generates an authentication assertion by signing information including the authentication result of the received biometric information and the base ID with the private key (step S7). Then, the authenticator 100 transmits an authentication response including the authentication assertion to the authentication server 1 (step S8).

[0055] The authentication server 1 verifies the received authentication assertion (step S9). Specifically, the authentication server 1 identifies a public key based on the authentication assertion, and verifies the signature of the private key in the authentication assertion using the identified public key. By using the base ID included in the authentication assertion, the authentication server 1 can reject authentication using a private key generated by a different authenticator 100 (spoofing) and authentication to an unintended site by using the base ID.

[0056] If the base ID included in the authentication assertion is unregistered (permitted in the authentication control policy), the authentication server 1 newly registers the base ID based on the authentication assertion (two base IDs are bound to one public key). In other words, the authentication server 1 performs new registration so that two base IDs are bound to one public key. This allows authentication to be performed even if an authentication request is received from either of the two authenticators 100 permitted by the authentication control policy.

[0057] If the authentication server 1 is able to confirm that the user is the real user as a result of the verification, it notifies the user of the authentication result indicating that the authentication was successful; if the authentication server 1 is unable to confirm that the user is the real user, it notifies the user of the authentication result indicating that the authentication was unsuccessful (step S10).

[0058] In this manner, in the present disclosure, by linking the base ID to the private key, it is possible to prevent spoofing and unintentional login to a phishing site. That is, according to the authentication system S according to the embodiment, it is possible to further improve the security of providing and storing personal privacy information.

[0059] Next, the aggregation control of private keys will be described with reference to Figures 1F and 1G. A private key is created for each combination of an authentication device, an authentication target, and a user's account. For this reason, if a user owns multiple terminal devices (authentication devices), the user needs to be aware of which private key (i.e., which account) is linked to each authenticator (terminal device). However, as the number of private keys increases, it becomes more difficult for the user to know which authenticator each private key resides in.

[0060] Therefore, in the present disclosure, the number of private keys that a user must know is reduced by aggregating the private keys registered in each authenticator into a meta authenticator. In this way, by aggregating the private keys registered in each authenticator into a meta authenticator, the private keys can be appropriately managed.

[0061] Hereinafter, the aggregation control of private keys will be specifically described with reference to Fig. 1F and Fig. 1G. First, in Fig. 1F, it is assumed that a plurality of authenticators (a first authenticator and a second authenticator) are installed or physically connected to one user terminal 200.

[0062] In this case, the user terminal 200 installs a meta authenticator that is a higher-level authenticator than the first authenticator and the second authenticator (step S1). The meta authenticator is realized as an application or middleware.

[0063] Next, the meta authenticator acquires the private keys A to F registered in the first authenticator and the second authenticator, respectively (step S2). In Fig. 1F, private keys A, B, and C are registered in the first authenticator, and private keys D, E, and F are registered in the second authenticator.

[0064] Private key A is the private key for user ID "U1" and first authentication subject "SA". Private key B is the private key for user ID "U2" and first authentication subject "SA". Private key C is the private key for user ID "U1" and second authentication subject "SB". Private key D is the private key for user ID "U1" and first authentication subject "SA". Private key E is the private key for user ID "U2" and first authentication subject "SA". Private key F is the private key for user ID "U1" and second authentication subject "SB".

[0065] The meta authenticator may obtain the private keys registered in the first authenticator and the second authenticator, for example, by deployment control using the private key capsule shown in FIG. 1B.

[0066] Next, the meta authenticator aggregates the acquired private keys A to F (step S3). Specifically, the meta authenticator aggregates for each combination of an authentication target and a user's account in the authentication target. For example, in FIG. 1F, private key A of the first authenticator and private key D of the second authenticator are the same authentication target and account, so both private keys are aggregated. Similarly, private key B of the first authenticator and private key E of the second authenticator are the same authentication target and account, so both private keys are aggregated. Similarly, private key C of the first authenticator and private key F of the second authenticator are the same authentication target and account, so both private keys are aggregated.

[0067] An example of the aggregation method is to discard one private key and register the other private key in the meta authenticator. As a result, as shown in Fig. 1F, private keys A, B, and C are registered in the meta authenticator, and private keys D, E, and F are discarded. Note that although private keys A to C of the first authenticator are registered in Fig. 1F, private keys D to F of the second authenticator may be registered. Alternatively, at least one private key each of the first authenticator and the second authenticator may be registered.

[0068] In this way, by aggregating multiple private keys registered in multiple authentication devices in the meta authentication device, it is possible to consolidate private keys that have overlapping combinations of authentication targets and accounts, thereby enabling appropriate management of private keys.

[0069] Next, with the collection of private keys completed, the meta authenticator performs authentication processing in steps S4 to S8. Specifically, when a user attempts to log in to a service, the meta authenticator makes an authentication request with the authentication server 1 (step S4). Figure 1F shows an example of authentication of the user ID "U2", which is the user's account, and the first authentication subject "SA".

[0070] In step S4, the meta-authenticator sends an authentication request to authenticate the login of account "U2" to authentication server 1 of the first authentication subject "SA". Then, authentication server 1 generates an authentication request message based on the authentication request, and sends the authentication request message and a challenge to the meta-authenticator.

[0071] Next, in step S5, the meta authenticator calls the first authenticator in which private key B is registered, based on private key B associated with user ID "U2" and first authentication subject "SA" (step S5).

[0072] Next, in step S6, the called first authenticator locally verifies the identity of the user (step S6). That is, the first authenticator requests the user to input biometric information in accordance with the authentication request message, and accepts the biometric information from the user.

[0073] Next, in step S7, the first authenticator uses private key B to sign the result of the verification of identity and generate an authentication assertion (step S7).

[0074] Next, the meta authenticator obtains an authentication assertion from the first authenticator and sends an authentication response including the authentication assertion to the authentication server 1 (step S8). The authentication server 1 then identifies a public key based on the authentication assertion and verifies the signature of the private key in the authentication assertion using the identified public key. If the authentication server 1 is able to confirm that the user is the correct user as a result of the verification, it notifies the authentication result indicating that the authentication was successful, and if the authentication server 1 is unable to confirm that the user is the correct user, it notifies the authentication result indicating that the authentication was unsuccessful.

[0075] 1F shows a state in which one meta authenticator is installed in user terminal 200, but this is not limiting. For example, user terminal 200 may have multiple meta authenticators, each linked to an authenticator, and may be configured in a hierarchical structure in which multiple meta authenticators are linked to a higher-level meta authenticator.

[0076] Next, another example of private key aggregation control will be described with reference to Fig. 1G. Fig. 1G shows an example in which a user has multiple user terminals 200a, 200b. In Fig. 1G, user terminal 200a is the same as user terminal 200 in Fig. 1F, and private keys A to F are registered in the first authenticator and second authenticator, and are aggregated into private keys A to C in the first meta authenticator. User terminal 200b has a third authenticator, and private keys G to I are registered. Furthermore, a second meta authenticator is installed in user terminal 200b.

[0077] In this configuration, the first meta authenticator of user terminal 200a synchronizes the private keys A to C registered therein with the second meta authenticator of user terminal 200b (step S1). Specifically, the first meta authenticator transmits the private keys A to C to the second meta authenticator. One method for transmitting the private keys A to C registered in the first meta authenticator to the second meta authenticator is, for example, by deployment control using the private key capsule shown in FIG. 1B.

[0078] Next, the second meta authenticator aggregates private keys (step S2). Specifically, the second meta authenticator aggregates private keys A to C obtained from the first meta authenticator and private keys G to I obtained from the third authenticator. Private key G is the private key of user ID "U1" and first authentication subject "SA". Private key H is the private key of user ID "U2" and first authentication subject "SA". Private key I is the private key of user ID "U1" and second authentication subject "SB".

[0079] For example, in Figure 1G, private key A of the first meta authenticator and private key G of the third authenticator are aggregated because they have the same authentication target and account. Similarly, private key B of the first meta authenticator and private key H of the third authenticator are aggregated because they have the same authentication target and account. Similarly, private key C of the first meta authenticator and private key I of the third authenticator are aggregated because they have the same authentication target and account.

[0080] An example of the aggregation method is to discard one private key and register the other private key in the meta authenticator. As a result, as shown in Fig. 1G, private keys A, B, and C are registered in the second meta authenticator, and private keys G, H, and I are discarded. Note that, although private keys A to C of the first meta authenticator are registered in the second meta authenticator in Fig. 1G, private keys G to I of the third authenticator may be registered. Alternatively, at least one private key of each of the first meta authenticator and the third authenticator may be registered in the second meta authenticator.

[0081] Next, with the collection of private keys completed, the second meta-authentication device performs authentication processing in steps S3 to S7. Specifically, when a user attempts to log in to a service, the second meta-authentication device makes an authentication request with the authentication server 1 (step S3). Figure 1G shows an example of authentication of the user ID "U2" which is the user's account and the first authentication subject "SA".

[0082] In step S3, the second meta-authenticator sends an authentication request to authenticate the login of account "U2" to authentication server 1 of the first authentication subject "SA". Then, authentication server 1 generates an authentication request message based on the authentication request, and sends the authentication request message and a challenge to the second meta-authenticator.

[0083] Next, in step S4, the second meta authenticator calls the third authenticator based on the private key B linked to the user ID "U2" and the first authentication subject "SA" (step S4). Specifically, in Fig. 1G, since the second meta authenticator is not connected to the first authenticator corresponding to the private key B, it calls the third authenticator in which the private key H linked to the same user ID "U2" as the private key B and the first authentication subject "SA" is registered.

[0084] Next, in step S5, the called third authenticator locally verifies the identity of the user (step S5). That is, the third authenticator requests the user to input biometric information in accordance with the authentication request message, and accepts the biometric information from the user.

[0085] Next, in step S6, the second meta authenticator obtains the result of the authentication from the third authenticator, and signs the result of the authentication using private key B to generate an authentication assertion (step S6). In other words, since the third authenticator cannot sign with private key B, the second meta authenticator which has private key B performs the signing.

[0086] Next, the second meta-authenticator sends an authentication response including an authentication assertion to the authentication server 1 (step S7). The authentication server 1 then identifies a public key based on the authentication assertion, and verifies the signature of the private key in the authentication assertion using the identified public key. If the authentication server 1 is able to confirm that the user is the correct user as a result of the verification, it notifies the authentication server 1 of an authentication result indicating that the authentication was successful, and if the authentication server 1 is unable to confirm that the user is the correct user, it notifies the authentication server 1 of an authentication result indicating that the authentication was unsuccessful.

[0087] In this way, even if a user possesses multiple user terminals 200a, 200b, private keys with overlapping combinations of authentication targets and accounts can be consolidated by synchronizing and aggregating private keys between the meta authenticators of each user terminal 200, thereby enabling appropriate management of private keys. That is, in the example of Fig. 1G, nine private keys A to I are aggregated and it is sufficient to manage only three private keys A to C.

[0088] 1F and 1G show an example in which each combination of authentication target and account is aggregated into one secret key, but the aggregation method is not limited to this. For example, the meta authenticator may aggregate multiple secret keys with different authentication methods for each combination of authentication target and account.

[0089] For example, if the first authenticator is a fingerprint authenticator and the second authenticator is a face authenticator, the meta authenticator (first meta authenticator) registers (aggregates) the private key A (for fingerprint authentication) of the first authenticator and the private key D (for face authentication) of the second authenticator in the meta authenticator. This allows the meta authenticator to perform two-factor authentication using fingerprint authentication and face authentication.

[0090] In this two-factor authentication, the meta authenticator may perform authentication processing (steps S4 to S8 in FIG. 1F) for each authentication method, for example. In other words, the meta authenticator performs face authentication as the first authentication processing, and then fingerprint authentication as the second authentication processing, and finally permits login if both authentications are successful.

[0091] Furthermore, in such two-factor authentication, the embodiment is not limited to one in which both fingerprint authentication and face authentication are performed, and an authentication method to be performed may be selected according to, for example, context information of a user. For example, the meta authenticator selects and performs face authentication when the context information indicates that the user is at home, and selects and performs fingerprint authentication when the context information indicates that the user is out. This can increase the security of authentication, and can increase the user's satisfaction with authentication by performing authentication that matches the context.

[0092] Next, a configuration example of the authentication server 1 will be described with reference to FIG.

[0093] Fig. 2 is a diagram showing a configuration example of an authentication server 1 according to an embodiment. As shown in Fig. 2, the authentication server 1 includes a communication unit 2, a control unit 3, and a storage unit 4. The storage unit 4 stores user information 41, public key information 42, and authentication control policy information 43.

[0094] The communication unit 2 is realized by, for example, a network interface card (NIC) etc. The communication unit 2 is connected to a network by wire or wirelessly.

[0095] The control unit 3 is a controller, and is realized by, for example, a processor such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit) executing various programs (corresponding to an example of a control program) stored in a storage device inside the authentication server 1 using a RAM or the like as a working area. The control unit 3 is also a controller, and may be realized by, for example, an integrated circuit such as an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a GPGPU (General Purpose Graphic Processing Unit).

[0096] The control unit 3 executes the processes related to the authentication process shown in FIGS. 1A and 1B.

[0097] The storage unit 4 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 or an optical disk.

[0098] The user information 41 is information related to a user. Fig. 3 is a diagram showing an example of the user information 41. As shown in Fig. 3, the user information 41 includes items such as "user ID" and "attribute information".

[0099] The "user ID" is identification information for identifying a user. The "attribute information" is information about the attributes of the user. The attribute information includes, for example, psychographic attributes and demographic attributes.

[0100] The public key information 42 is information related to a public key. Fig. 4 is a diagram showing an example of the public key information 42. As shown in Fig. 4, the public key information 42 includes items such as a "public key," a "user ID," and a "base ID."

[0101] The "public key" is information that indicates the public key. The "user ID" is identification information that identifies the user. The "base ID" is base information.

[0102] The authentication control policy information 43 is information related to an authentication control policy. Fig. 5 is a diagram showing an example of the authentication control policy information 43. As shown in Fig. 5, the authentication control policy information 43 includes items such as "user ID" and "permission base ID".

[0103] "User ID" is identification information for identifying a user. "Authorized base ID" is identification information for identifying an authorized private key management environment. Note that while FIG. 5 shows an example including an "authorized base ID" which is authorized private key management environment information, it may also include information on a "forbidden base ID" which is prohibited private key management environment identifier information.

[0104] Next, a configuration example of the authentication device 100 will be described with reference to FIG.

[0105] Fig. 6 is a diagram showing an example of the configuration of an authentication device 100 according to an embodiment. As shown in Fig. 6, the authentication device 100 has a communication unit 110, a control unit 120, and a storage unit 130. The storage unit 130 stores private key capsule information 131 and deployment policy information 132.

[0106] The communication unit 110 is realized by, for example, a NIC etc. The communication unit 110 is connected to a network by wire or wirelessly.

[0107] The control unit 120 is a controller, and is realized, for example, by a processor such as a CPU or an MPU executing various programs (corresponding to an example of a control program) stored in a storage device inside the authentication device 100 using a RAM or the like as a working area. The control unit 120 is also a controller, and may be realized, for example, by an integrated circuit such as an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a GPGPU (General Purpose Graphic Processing Unit).

[0108] The control unit 120 executes the processes related to the authentication process shown in FIGS. 1A to 1E.

[0109] The storage unit 130 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 or an optical disk.

[0110] Private key capsule information 131 is information related to a private key capsule. Fig. 7 is a diagram showing an example of private key capsule information 131. As shown in Fig. 7, private key capsule information 131 includes items such as "capsule ID", "private key", "user ID", "base ID", and "context information".

[0111] "Capsule ID" is identification information that identifies the private key capsule. "Private key" is private key information. "User ID" is identification information that identifies the user. "Base ID" is base information. "Context information" is the context information shown in Figure 1B.

[0112] The deployment policy information 132 is information related to a deployment policy. Fig. 5 is a diagram showing an example of the deployment policy information 132. As shown in Fig. 8, the deployment policy information 132 includes items such as "user ID" and "permission base ID".

[0113] The "user ID" is identification information for identifying a user. The "authorized base ID" is identification information for identifying an authorized private key management environment. Note that while FIG. 8 shows an example including an "authorized base ID" which is identification information for identifying an authorized private key management environment, it may also include information on a "prohibited base ID" which is identification information for identifying a prohibited private key management environment.

[0114] 〔others〕 In addition, among the processes described in the above embodiments, some of the processes described as being performed automatically can be performed manually. Alternatively, all or some 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 arbitrarily unless otherwise specified. For example, the various information shown in each drawing is not limited to the illustrated information.

[0115] 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 according to various loads, usage conditions, etc.

[0116] 2 may be held in a storage server or the like instead of being held by each device. In this case, each device obtains various pieces of information by accessing the storage server.

[0117] [Hardware configuration] Moreover, the authentication server 1 and the authentication device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration as shown in Fig. 9, for 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 IF (Interface) 1060, an input IF 1070, and a network IF 1080 are connected by a bus 1090.

[0118] The arithmetic device 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050 and programs read from the input device 1020, and executes various processes. The primary storage device 1040 is a memory device, such as a RAM, 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), a HDD (Hard Disk Drive), a flash memory, or the like.

[0119] The output IF 1060 is an interface for transmitting information to be output to an output device 1010 that outputs various types of information, such as a monitor or a printer, 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 IF 1070 is an interface for receiving information from various input devices 1020, such as a mouse, keyboard, and scanner, and is realized by a USB, for example.

[0120] 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 input device 1020 may also be an external storage medium such as a USB memory.

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

[0122] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output IF 1060 and the input IF 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.

[0123] For example, when the computer 1000 functions as the authentication server 1 or the authentication device 100, the arithmetic unit 1030 of the computer 1000 realizes the functions of the control unit 3, 120 by executing a program loaded onto the primary storage device 1040.

[0124] 〔effect〕 As described above, the information processing device (user terminal 200) according to the embodiment includes a control unit that acquires multiple private keys registered in multiple authentication devices used by the same user, and aggregates the acquired multiple private keys for each combination of an authentication target and the user's account in the authentication target. With this configuration, private keys can be appropriately managed.

[0125] Although some of the embodiments of the present application have been described in detail above with reference to the drawings, these are merely examples, and the present invention can be embodied in other forms that incorporate various modifications and improvements based on the knowledge of those skilled in the art, including the forms described in the Disclosure of the Invention section.

[0126] 〔others〕 In addition, 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 by 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 arbitrarily unless otherwise specified. For example, the various information shown in each drawing is not limited to the illustrated information.

[0127] 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 according to various loads, usage conditions, etc.

[0128] Furthermore, the processes described in the above-described embodiments can be appropriately combined as long as the process contents are not contradictory.

[0129] Moreover, the above-mentioned "section, module, unit" can be read as "means" or "circuit", etc. For example, the control unit 3 can be read as control means or a control circuit. [Explanation of symbols]

[0130] 1 Authentication Server 2. Communications Department 3. Control Unit 4 Storage section 41 User information 42 Public Key Information 43 Authentication Control Policy Information 100 Authenticators 110 Communications Department 120 Control section 130 Storage section 131 Private Key Capsule Information 132 Deployment Policy Information S Authentication System

Claims

1. A control unit that acquires a plurality of private keys registered in a plurality of authentication devices used by the same user, and aggregates the acquired plurality of private keys for each combination of an authentication target and an account of the user in the authentication target. An information processing device comprising:

2. The control unit is When there are multiple private keys with the same combination of the authentication target and the account, one of the multiple private keys is registered and the others are discarded to consolidate the multiple private keys. The information processing device according to claim 1 .

3. The control unit is When login authentication is performed using the collected private key, the authentication device corresponding to the private key associated with the authentication subject and the account of the login subject is called to perform identity verification. The information processing device according to claim 1 .

4. The control unit is The authentication device executes a signature using the private key on the result of the authentication. The information processing device according to claim 3 .

5. The control unit is A plurality of private keys acquired from an authentication device associated with another terminal device and a plurality of private keys registered in an authentication device associated with the terminal device are aggregated for each combination of the authentication target and the account. The information processing device according to claim 1 .

6. The control unit is When login authentication is performed using the aggregated private key, if the private key is registered in an authentication device of the other terminal device, an authentication device in which a private key having the same private key as the authentication target and the account as the private key is registered is identified from among the authentication devices linked to the own terminal device, and identity verification is performed using the identified authentication device. The information processing device according to claim 5 .

7. The control unit is The authentication result is obtained from the authentication device, and a signature is made using the aggregated private key registered to the authentication device. The information processing device according to claim 6.

8. The control unit is The authentication method is aggregated into a plurality of secret keys, each of which has a different authentication method for each combination of the authentication target and the account. The information processing device according to claim 1 .

9. The authentication method includes: Includes at least face recognition and fingerprint recognition The information processing device according to claim 8.

10. The control unit is When login authentication is performed using the aggregated multiple private keys, authentication is performed for each of the authentication methods. The information processing device according to claim 9.

11. The control unit is When login authentication is performed using the aggregated private keys, the authentication method to be used for authentication is selected according to user context information. The information processing device according to claim 9.

12. 1. A computer-implemented information processing method, comprising: A control process for acquiring a plurality of private keys registered in a plurality of authentication devices used by the same user, and aggregating the acquired plurality of private keys for each combination of an authentication target and an account of the user in the authentication target. An information processing method comprising:

13. A control procedure for acquiring a plurality of private keys registered in a plurality of authentication devices used by the same user, and aggregating the acquired plurality of private keys for each combination of an authentication target and an account of the user in the authentication target. An information processing program that causes a computer to execute the above.

Images