JP6823564B2 - Authentication key sharing system and new terminal registration method - Google Patents

Description

The present invention relates to an authentication key sharing system in which a user uses an authentication key necessary for using a Web service from a terminal, and a method for newly registering a terminal.

Internet users use various Web (World Wide Web) services such as online banking and online shopping by using terminals such as personal computers (personal computers), smartphones, and tablets. When using a Web service (also simply referred to as a service), user authentication is required, and it is common to use a user ID (IDentifier) and a password. However, there are many cases in which a password is stolen because the password set easily is guessed or the password is leaked from a Web server (also called a server) that provides a Web service due to unauthorized access.

As a user authentication technology that replaces password authentication, there is a user authentication technology for Web services that uses public key cryptography called FIDO (Fast IDentity Online). In FIDO, a pair of private key and public key authentication key pairs, which are different for each service, are generated by the terminal, the public key is registered in the server, and the private key is confined in the secure area in the terminal. For example, as shown in FIG. 15A, the public key 11a is registered in the Web server 10a that provides the predetermined service A, and the public key 11b is registered in the Web server 10b that provides the predetermined service B. The private key 14a paired with the public key 11a and the private key 14b paired with the public key 11b are confined in the secure area 13a of the terminal 12a. In addition, "to pair" means "to pair". The same applies thereafter.

User authentication by the server (for example, 10a) is performed as follows by signature in challenge / response authentication (described later). That is, a procedure in which the server 10a generates a random number and transmits it to the terminal 12a, the terminal 12a signs the random number using the private key 14a and returns it to the server 10a, and the server 10a verifies the signature with the public key 11a. It is done in. If the signature verification is successful, the user authentication is successful, and the user can use the Web service. Challenge-response authentication is an authentication method that prevents passwords and the like from being eavesdropped during communication by applying special processing to a random character string (called a challenge) used for user authentication.

When the user uses the private keys 14a and 14b of the terminal 12a before the user authentication by the server, it is premised that the user is authenticated on the terminal 12a by biometric authentication or the like. The private keys 14a and 14b are used within the secure area 13a of the terminal 12a, and the private keys 14a and 14b are not exposed to the outside of the terminal 12a, so that high security is maintained.

However, when the new terminal 12b shown in FIG. 15B is used, since there is no private key in the secure area 13b, an authentication key pair is generated again for each of the services A and B of the Web servers 10a and 10b. And you need to register the private key. At this time, when using a plurality of terminals, registration work is required for the number of terminals x the number of services. Therefore, the greater the number of terminals and services, the lower the convenience.

Therefore, Non-Patent Document 1 discloses a method in which a plurality of private keys are aggregated in a keystore (described later) outside the terminal, and the keystore can be shared and used by the plurality of terminals. This method will be described with reference to FIG.

The keystore 17 shown in FIG. 16 is composed of a server or the like, and has a terminal key storage area 18 and an authentication key storage area 19. The terminals 12a and 12b hold the terminal key {hereinafter referred to as the terminal key (secret)} 20a and 20b as the private key, present the identity verification information guaranteed by a third party to the keystore 17, and present the terminal key (the terminal key (secret)). (Secret) The terminal key {hereinafter referred to as the terminal key (public)} 15a, 15b as a public key paired with the 20a, 20b is registered in the terminal key storage area 18. In the authentication key storage area 19, an authentication key {hereinafter referred to as an authentication key (secret)} 16a, 16b as a private key is registered. The authentication key (secret) 16a has a one-to-one correspondence with the authentication key {hereinafter referred to as the authentication key (public)} 11a as the public key associated with the service A of the server 10a, and the authentication key (secret) 16b has a one-to-one correspondence with the authentication key (public) 11b associated with the service B of the server 10b.

The terminal (for example, 12a) generates a pair of the terminal key (secret) 20a and the terminal key (public) 15a, holds the terminal key (secret) 20a in the own terminal 12a, and holds the terminal key (public) 15a as the key. Presented to the store 17, the key store 17 holds the terminal key (public) 15a. After this holding, the terminal 12a transfers a random number related to the service (for example, A) to be used to the keystore 17, and in the keystore 17, the authentication key (public) 11a paired with the authentication key (public) 11a of the service A is paired with the authentication key (secret). At 16a, we request that the random number be signed. The keystore 17 signs the random number with the authentication key (secret) 16a and returns it to the terminal 12a. Further, the terminal 12a returns the signed random number received from the keystore 17 to the server 10a. The server 10a verifies the signature with the authentication key (public) 11a, and if this verification is OK, the service A can be used for the terminal 12a.

In this way, the terminals 12a and 12b may register the terminal keys (public) 15a and 15b paired with the terminal keys (secret) 20a and 20b held by the terminal itself in the keystore 17. By this registration, the terminals 12a and 12b are asked to sign a random number with the authentication keys (secret) 16a and 16b stored in the authentication key storage area 19 after conforming to the authentication by the terminal keys (secret) 20a and 20b and reply. As a result, arbitrary services A and B can be used. Further, when the terminal keys (public) 15a and 15b are registered in the keystore 17 by the terminals 12a and 12b, the identity verification process of the terminal owner is performed so that only the terminals 12a and 12b belonging to the same owner can be registered. The mechanism is such that the authentication keys (secret) 16a and 16b on the keystore 17 cannot be used. Therefore, high security is maintained.

Yusuke Ogata, Yoshihiko Omori, Takao Yamashita, Tetsuya Iwata, "Consideration on Maintenance and Management of Private Keys for Authentication Methods Using Asymmetric Keys", IEICE Communication Society Conference, B-7-9, 2016

In the method using the keystore 17 described above, the terminal key (in order to make the authentication keys (secret) 16a and 16b on the keystore 17 accessible only to the terminals 12a and 12b of the same owner) is used in the keystore 17. Public) Register 15a and 15b. When performing this registration, it is premised that the identity verification information guaranteed by a third party is presented, so it is necessary to present the identity verification information every time the terminals 12a and 12b are newly added.

There are various ways to present identity verification information, but in order to prevent spoofing due to unauthorized access to the keystore 17, it is assumed that identity verification of a certain level or higher is required based on a guarantee by a third party. , The burden on the user is not small. Specifically, there are the following methods (1) to (3) that are generally practiced.

(1) Face-to-face identification.
(2) Send the confirmation code to the pre-registered email address or phone number {SMS (short message) number}, and enter the confirmation code on the new terminal.
(3) Bring an IC (integrated circuit) card whose identity has been confirmed (eg, My Number card, etc.) into contact with the terminal.

Assuming the current usage environment in which users generally use a few terminals exclusively to use the service, the burden of performing identity verification only at the start of using the terminals is within the permissible range. Is assumed.

However, if the number of terminals owned, including wearable terminals, increases dramatically in the future, or if shared terminals existing in various locations are temporarily occupied and the service is used, at the end of use. It is expected that usage styles that release will be generalized. In this case, every time a new terminal is added or a shared terminal is used, it is necessary to present the identity verification information and register the terminal key (public) in the keystore, which causes a problem that the burden on the user is heavy. Occurs.

The present invention has been made in view of such circumstances, and even if the number of terminals owned by the same user increases, the Web service can be conveniently used from the terminals while ensuring a certain level of security. An object of the present invention is to provide an authentication key sharing system and a new terminal registration method that can use the authentication key required for the purpose.

As a means for solving the above problems, the invention according to claim 1 is an authentication as a server that provides various services by communication, a terminal that uses the services in communication, and a public key that authenticates the services. A key (public), an authentication key (secret) as a private key for service authentication paired with the authentication key (public), and a terminal key (secret) as a private key for the terminal held by the terminal. It is an authentication key sharing system having a key store in which a terminal key (public) as a pair of public keys is registered. If there is a registered terminal in which the terminal key (secret) held by the machine and the terminal key (public) paired with it are registered in the key store, the terminal key (secret) held in the newly registered new terminal The terminal key (public) paired with is signed with the terminal key (secret) held by the registered terminal, and the signed terminal key (public) generated by this signature is transmitted to the key store. The key store is provided with a unit, and when the signature of the signed terminal key (public) is verified by the terminal key (public) of the registered terminal held in the key store, the new terminal A terminal management unit that registers a terminal key (public) in the key store is provided , and the registered terminal transmits the usage conditions that restrict the use of the service to the new terminal, and the key of the new terminal is transmitted. At the time of registration of the terminal key (public) in the store, the usage conditions are transmitted to the key store, and the key store restricts the use of the service of the new terminal according to the usage conditions. It is a featured authentication key sharing system.

The invention according to claim 8 is a server that provides various services by communication, a terminal that uses the service in communication, an authentication key (public) as a public key for authenticating the service, and the authentication key (public). ) And the authentication key (secret) as the private key for service authentication, and the terminal key (public) as the public key paired with the terminal key (secret) as the private key for the terminal held by the terminal. ) is a terminal new registration method of authentication key sharing system and a key store that is registered, the terminal key to presenting a personal identification information by third parties to guarantee, self-registered terminal is held (secret) When there is a registered terminal in which the terminal key (public) paired with is registered in the key store, the registered terminal is paired with the terminal key (secret) held in the newly registered new terminal. The terminal key (public) of is signed with the terminal key (secret) held by the registered terminal, and the signed terminal key (public) generated by this signature is transmitted to the key store. In the key store, when the signature of the signed terminal key (public) is verified with the terminal key (public) of the registered terminal held in the key store, the terminal key (public) of the new terminal is used. ) Is executed in the key store, the registered terminal executes a step of transmitting a usage condition for restricting the use of the service to the new terminal, and the new terminal executes the step of transmitting the usage conditions to restrict the use of the service. When the terminal key (public) is registered in the key store, the step of transmitting the usage conditions to the key store is executed, and the key store restricts the use of the service of the new terminal according to the usage conditions. This is a new terminal registration method characterized by executing steps .

According to the configuration of claim 1 and the method of claim 8, the terminal key (public) of the new terminal is signed with the terminal key (secret) of the registered terminal, and the signed terminal key (public) is used as the key. You can authenticate at the store and register the terminal key (public) of the new terminal. Therefore, when registering a new terminal in the keystore, it is possible to easily authenticate and register without presenting the identity verification information. Therefore, even if the number of terminals owned by the same user increases, it is possible to conveniently use the authentication key required for using the Web service from the terminals while ensuring a certain level of security.
In addition, new terminals registered by authentication based on signatures between terminals can be differentiated from registered terminals by presenting identity verification information by setting restrictions on the use of services.

The invention according to claim 2 includes a server that provides various services by communication, a terminal that uses the service in communication, an authentication key (public) as a public key for authenticating the service, and the authentication key (public). ) And the authentication key (secret) as the private key for service authentication, and the terminal key (public) as the public key paired with the terminal key (secret) as the private key for the terminal held by the terminal. ) Is an authentication key sharing system having a key store in which a third party guarantees identity verification information, and the terminal key (secret) held by the self-registered terminal. To identify a terminal received from the key store in response to a connection request for a new terminal to be newly registered when there is a registered terminal in which a pair of terminal keys (public) is registered in the key store. The registered terminal acquired from the new terminal signs the terminal identification challenge by the random character string of the above with the terminal key (secret) held by the registered terminal, and the signed terminal generated by this signature. A terminal key management unit that returns an identification challenge to the key store via the new terminal is provided, and the key store is a registered terminal in which the signature of the signed terminal identification challenge is held in the key store. A terminal management unit that registers the terminal key (public) of the new terminal in the key store when verified with the terminal key (public) is provided , and the registered terminal is transferred to the new terminal to provide the service. When the usage conditions for restricting the use are transmitted and the terminal key (public) of the new terminal is registered in the key store, the usage conditions are transmitted to the key store, and the key store is in accordance with the usage conditions. It is an authentication key sharing system characterized in that the use of the service of the new terminal is restricted .

According to this configuration, the terminal identification challenge from the new terminal is signed with the terminal key (secret) of the registered terminal, the signed terminal identification challenge is authenticated by the key store, and the terminal key of the new terminal ( Public) can be registered. Therefore, when registering a new terminal in the keystore, it is possible to easily authenticate and register without presenting the identity verification information.
In addition, new terminals registered by authentication based on signatures between terminals can be differentiated from registered terminals by presenting identity verification information by setting restrictions on the use of services.

The invention according to claim 3 is generated by signing with a terminal key (secret) held by the registered terminal when transmitting the terms of use from the registered terminal to the new terminal. and an authentication key agreement system according to claim 1, characterized in that transmitting the signed terminal key with the usage condition (public).

The invention according to claim 4, when transmitting the use condition from the registered terminal to the new terminal, signed with a terminal key (secret) which the registered terminal is held, generated by the signature of this The authentication key sharing system according to claim 2 , wherein the signed terminal identification challenge is transmitted with the terms of use.

According to the configurations of claims 3 and 4, the following effects can be obtained. New terminals registered by authentication based on signatures between terminals can be differentiated from registered terminals by presenting identity verification information by setting restrictions on the use of services.

The invention according to claim 5 has an access control unit that stores in the key store the information at the time of registration of the registered terminal and the terminal related to the new terminal in association with the unique information of the terminal. When the terminal uses the authentication key (secret) registered in the key store, the server responds to the information at the time of registration of the terminal received from the key store. The authentication key sharing system according to claim 1 or 2, further comprising an authentication key usage control unit that restricts the use of the authentication key (secret).

According to this configuration, in the server, the use of the service to the terminal can be restricted by restricting the use of the authentication key (secret) of the terminal according to the information at the time of registration of the terminal.

In the invention according to claim 6, both the new terminal and the registered terminal are used before the terminal communicates for the signature between the new terminal and the registered terminal. The present invention according to any one of claims 1 to 5, further comprising a mutual confirmation unit that establishes communication between the two when predetermined operations are simultaneously performed at a predetermined distance. It is an authentication key sharing system.

According to this configuration, communication between terminals is established only when predetermined operations are simultaneously performed within a predetermined distance, for example, within 2 m, so that security is established. It is possible to improve the convenience of the user who uses the terminal while improving the above.

In the invention according to claim 7, the keystore associates the identity verification information with the registered terminal registered in the keystore by presenting the identity verification information, and the registered terminal and the new terminal. A new terminal whose signature of the signed terminal key (public) generated by the signature in between is verified and registered in the keystore is provided with an access control unit that associates trust information with the terminal management table and saves it in the terminal management table. The authentication key sharing system according to any one of claims 1 to 6, wherein the authentication key sharing system is characterized in that.

According to this configuration, in the terminal management table of the keystore, the registered terminal is associated with the identity verification information, and the new terminal is associated with the trust information. This makes it possible to easily identify whether the terminal registered in the keystore is authenticated by the identity verification information or simply authenticated by the signature between the terminals. .. Therefore, it can be accurately identified when the usage conditions are attached to the terminal.

According to the present invention, even if the number of terminals owned by the same user increases, an authentication key that conveniently uses an authentication key necessary for using a Web service from a terminal while ensuring a certain level of security. It is possible to provide a shared system and a new terminal registration method.

It is a block diagram which shows the structure of the authentication key sharing system which concerns on this invention. It is a block diagram which shows the structure of the authentication key sharing system which concerns on 1st Embodiment of this invention. It is a block diagram of a terminal management table. It is a block diagram of a key management table. It is a sequence diagram for demonstrating the registration process of the terminal by the identity verification information of 1st Embodiment. It is a sequence diagram for demonstrating the registration process of the terminal by the trust information of 1st Embodiment. It is a sequence diagram for demonstrating the registration process of the authentication key of 1st Embodiment. It is a sequence diagram for demonstrating the user authentication process at the time of using the service of 1st Embodiment. It is a block diagram which shows the structure of the authentication key sharing system which concerns on 2nd Embodiment of this invention. It is a sequence diagram for demonstrating the registration process of the terminal by the trust information of 2nd Embodiment. It is a block diagram which shows the structure of the authentication key sharing system which concerns on 3rd Embodiment of this invention. It is a sequence diagram for demonstrating the registration process of the terminal by the trust information of 3rd Embodiment. It is a sequence diagram for demonstrating the registration process of the authentication key of 3rd Embodiment. It is a sequence diagram for demonstrating the user authentication process at the time of using the service of 3rd Embodiment. The configuration of the user authentication technology of the Web service using the conventional public key cryptography is shown, (a) is a block diagram showing the case where the authentication key is in the secure area of the terminal, and (b) is the secure area of the terminal. It is a block diagram which shows the case where there is no authentication key. It is a block diagram which shows the structure of the conventional authentication key sharing system.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
First, the principle of the present invention will be described with reference to FIG. FIG. 1 is a block diagram showing a configuration of an authentication key sharing system 30 according to the present invention.
The authentication key sharing system (also referred to as a system) 30 is used by a user (user) and Web servers (also referred to as servers) 31a and 31b that provide various Web services (also referred to as services) such as online banking and online shopping. It is configured to include first and second terminals 32a and 32b such as a personal computer, a smartphone, and a tablet, and a key store 33 composed of a server and the like.

The servers 31a and 31b hold the authentication keys (public) K1a and K1b associated with the services A and B. In the keystore 33, authentication keys (public) K1a and K1b of servers 31a and 31b and paired authentication keys (secret) K4a and K4b are registered. The first terminal 32a holds the terminal key (secret) K2a, presents the identity verification information guaranteed by a third party to the key store 33, and sets the terminal key (public) K3a paired with the terminal key (secret) K2a. Register in the keystore 33. The second terminal 32b holds the terminal key (secret) K2b, and registers the terminal key (public) K3b paired with the terminal key (secret) K2b in the key store 33 as described later.

The user uses the first and second terminals 32a and 32b to use various services of the servers 31a and 31b. At this time, the terminal key (public) K3a of the first terminal 32a holding the terminal key (secret) K2a is registered in the key store 33 by presenting the user's identity verification information as shown by the arrow Y1. And. In this case, when the user uses a new terminal (for example, the second terminal 32b), in the present invention, the terminal key (public) K3b of the new terminal 32b is registered in the key store 33 as follows. Do.

In the present invention, when registering a new second terminal 32b in the keystore 33, the first terminal 32a already registered and the two-way arrow Y2 do not need to present the identity verification information guaranteed by a third party. As shown in the above, mutual confirmation is performed to establish communication between the terminals 32a and 32b, and it is considered that the owners are simply confirmed to be the same. Upon this confirmation OK, the first terminal 32a presents the trust information. Then, as shown by the arrow Y3, the registration of the terminal key (public) K3b of the second terminal 32b (also referred to as the registration of the terminal) is allowed based on the presentation of the trust information of the first terminal 32a. It has become.

The above mutual confirmation is conditional on the first and second terminals 32a and 32b being simultaneously executed at a predetermined short distance (a short distance within 2 m). .. Specific examples of means for mutual confirmation include connecting terminals 32a and 32b with a short cable having a predetermined length such as a USB cable, RFID (Radio Frequency Identification), NFC (Near Field Communication), and BLE ( Connect by short-range wireless with Bluetooth (registered trademark) Low Energy), etc., and enter the same confirmation code to establish short-range communication. The purpose of establishing this proximity communication is to prevent spoofing and enhance security.

Further, the second terminal 32b registered based on the mutual confirmation between the terminals 32a and 32b does not present the identity verification information guaranteed by a third party. Therefore, compared to the first terminal 32a in which the terminal key (public) K3a is registered by presenting the identity verification information, the authentication keys (secret) K4a and K4b of the keystore 33 are used under limited usage conditions. It is possible.

Limited examples of usage conditions include the following (1) to (3).
(1) After registering the terminal, the authentication keys (secret) K4a and K4b can be used only for a certain period of time.
(2) After registering the terminal, the authentication keys (secret) K4a and K4b can be used only a certain number of times.
(3) Only a specific authentication key (secret) (for example, K4a) can be used instead of all authentication keys (secret) K4a and K4b.

Such terms of use can be specified by the service provider who authenticates the user based on the existence of the authentication key (secret), or by the user who executes the registration process of the new terminal at the time of mutual confirmation. It can also be specified by the keystore administrator.

From this, as shown by the arrow Y4, the first terminal 32a can use any of the authentication keys (secret) K4a and K4b of the keystore 33 without any usage condition. As a result, any of the services A and B of the servers 31a and 31b can be used.

On the other hand, as shown by the arrow Y5, the second terminal 32b registered by mutual confirmation with the first terminal 32a can use only the authentication key (secret) K4a with usage conditions. Therefore, only the service A of the server 31a can be used.

<Structure of the first embodiment>
Next, the authentication key sharing system according to the first embodiment of the present invention will be described. FIG. 2 is a block diagram showing a configuration of the authentication key sharing system 30A according to the first embodiment of the present invention. However, in the system 30A, the same parts as those of the authentication key sharing system 30 shown in FIG. 1 are designated by the same reference numerals, and the description thereof will be omitted as appropriate.

The system 30A shown in FIG. 2 includes servers 31a and 31b that provide various services, first and second terminals 32a and 32b used by the user, and a keystore 33.

The server 31a includes an authentication unit 41a that holds an authentication key (public) K1a associated with the service A. The server 31b includes an authentication unit 41b that holds an authentication key (public) K1b associated with the service B. The authentication keys (public) K1a and K1b of the authentication units 41a and 41b are held by, for example, the key management table T4 (see FIG. 7).

The first terminal 32a includes a Web client 43a, a mutual confirmation unit 44a, a keystore access unit (also referred to as an access unit) 45a, and a terminal key management unit 46a that holds a terminal key (secret) K2a. The second terminal 32b includes a Web client 43b, a mutual confirmation unit 44b, a keystore access unit 45b, and a terminal key management unit 46b that holds a terminal key (secret) K2b.

The Web clients 43a and 43b are a Web browser, a smartphone application for using a service on the Web, and the like. The Web clients 43a and 43b are architectures that implement each software component that realizes FIDO authentication in addition to a server and a client (browser and Web application) for normally using a Web service in the FIDO technology that is the basis of the present invention. It has become. Since the present invention is also based on the present architecture, a Web client exists.

The key store 33 includes an access control unit 47, a terminal management unit 48 that holds terminal keys (public) K3a and K3b, and an authentication key management unit 49 that holds authentication keys (secret) K4a and K4b. The access management unit 47 includes the terminal management table T1 shown in FIG. The authentication key management unit 49 includes the key management table T2 shown in FIG.

<Terminal registration process based on the identity verification information of the first embodiment>
The process of registering the first terminal 32a in the keystore 33 using the identity verification information will be described with reference to the sequence diagram shown in FIG.
In step S1 shown in FIG. 5, the keystore access unit 45a of the terminal 32a makes a registration request of the own terminal 32a to the terminal management unit 48 of the keystore 33 by the user name. In step S2, the terminal management unit 48 instructs the request for the identity verification information to present the company X certificate (electronic certificate issued by the company X) certifying that the company X is a user of the terminal 32a. Do. This request is notified to the terminal key management unit 46a via the access unit 45a.

The terminal key management unit 46a performs biometric authentication in step S3. This is done, for example, by the user presenting his / her fingerprint to the fingerprint authentication means of the terminal 32a. In addition, there is biometric authentication such as vein authentication. If the biometric authentication is OK, the terminal key management unit 46a generates a pair of terminal key (secret) K2a and terminal key (public) K3a in step S4. Further, the terminal key management unit 46a holds the generated terminal key (secret) K2a in step S5 (FIG. 2), and outputs the terminal key (public) K3a to the access unit 45a in step S6.

The access unit 45a that has received the terminal key (public) K3a acquires the company X certificate in step S7. Here, it is a precondition that the identity verification of the user who owns the terminal 32a is performed in advance by the company X, and the company X certificate is issued by the company X as an electronic certificate. Next, in step S8, the access unit 45a sets the terminal ID of the own terminal 32a, the terminal key (public) K3a, and the company X certificate, and transmits the set to the terminal management unit 48 of the key store 33.

In step S9, the terminal management unit 48 confirms the contents of the company X certificate and verifies that the user is associated with the company X certificate. If this verification is OK, the terminal management unit 48 registers the corresponding terminal 32a in the access management unit 47 in step S10. This registration is performed by "D23094F1F" in which the first user is expressed in the user column of the terminal management table T1 in FIG. "...", identity verification information in the information column at the time of registration, no usage conditions in the usage conditions column "-", and so on. Hereinafter, the terminal key (public) K3a expressed in hexadecimal notation "D23094F1F ..." will be referred to as the terminal key (public) K3a "D23094F1F ...". The same applies to other keys. Here, the terminal key (public) K3a "D23094F1F ..." is registered as a public key using the terminal ID "Dev-1" as a key. In addition, since the identity verification information can be confirmed at the time of registration, it is registered as "-" with no usage conditions (all authentication keys can be used without restrictions).

In this way, it is assumed that the first terminal 32a is already registered in the key store 33. The first terminal 32a is also referred to as a registered terminal 32a.

<Registration process of new terminal of the first embodiment>
Next, a case where the second terminal 32b is newly registered in the key store 33 without presenting the identity verification information will be described. The second terminal 32b is also referred to as a new terminal 32b.

In the case of this new registration, the mutual confirmation unit 44b of the new terminal 32b shown in FIG. 2 obtains a terminal key (public) K3b paired with the terminal key (secret) K2b held in the terminal key management unit 46b after biometric authentication. , As shown by the arrow Y11, the transmission is performed to the mutual confirmation unit 44a of the registered terminal 32a. The mutual confirmation unit 44a signs the transmitted terminal key (public) K3b with the terminal key (secret) K2a held by the registered terminal 32a.

As shown by the arrow Y12, the registered terminal 32a returns the terminal key (public) K3a signed with the terminal key (secret) K2a to the new terminal 32b. As indicated by the arrow Y13, the new terminal 32b transmits the returned terminal key (public) K3b with the signature K2a1 to the keystore 33. The keystore 33 verifies that the terminal key (public) K3b with the signature K2a1 is signed with the terminal key (public) K3a of the registered terminal 32a held in the keystore 33, and the terminal key (public) ) Register K3b. Information registered based on verification between terminals 32a and 32b in this way is called trust information. This trust information is information signed by the terminal key (secret) K2a of the registered terminal 32a, and is registered in the information field at the time of registration of the terminal management table T1 shown in FIG. The signature K2a1 signed terminal key (public) K3b constitutes the signed terminal key (public) described in the claim.

<Terminal registration process based on the trust information of the first embodiment>
The process of registering the second terminal 32b in the keystore 33 by utilizing the trust information of the registered terminal 32a described above will be specifically described with reference to the sequence diagram shown in FIG.

In step S11 shown in FIG. 6, the mutual confirmation unit 44b of the second terminal 32b that newly registers makes a proximity communication establishment request to the mutual confirmation unit 44a of the registered first terminal 32a. This is a request for mutual confirmation for establishing communication by simultaneously operating two terminals 32a and 32b at a predetermined short distance (a short distance within 2 m).

In step S12, the first terminal 32a that has received the proximity communication establishment request displays a connection code (passcode) to be shown to the user on the display (not shown) of the first terminal 32a. This connection code is a code string for connecting between the terminals 32a and 32b. The user who sees the connection code displayed on the display inputs the connection code to the mutual confirmation unit 44b of the second terminal 32b in step S13.

In step S14, the mutual confirmation unit 44b of the second terminal 32b transmits the connection code to the mutual confirmation unit 44a of the first terminal 32a. Upon receiving this connection code, the mutual confirmation unit 44a transmits a proximity communication establishment response to the terminal key management unit 46b via the mutual confirmation unit 44b of the second terminal 32b in step S15. As a result, proximity communication between the terminals 32a and 32b is established.

The terminal key management unit 46b performs biometric authentication in step S16. If the biometric authentication is OK, the terminal key management unit 46b generates a pair of terminal key (secret) K2b and terminal key (public) K3b in step S17. Further, the terminal key management unit 46b holds the generated terminal key (secret) K2b in step S18 (FIG. 2), and manages the terminal key (public) K3b in the terminal key management of the first terminal 32a in step S19. It is transmitted to the unit 46a.

In the registered first terminal 32a, in step S20, the usage conditions (number of times of service use, time, etc.) of the second terminal 32b that the user newly registers are specified. After this designation, the terminal key management unit 46a performs biometric authentication in step S21. If this biometric authentication is OK, in step S22, the terminal key management unit 46a is the terminal key (secret) K2a held by the own terminal key management unit 46a, and the terminal key (public) K3b from the second terminal machine 32b. To sign. Then, in step S23, the terminal key management unit 46a transfers the signed and usage condition terminal key (public) K3b to the access unit 45b via the terminal key management unit 46b of the second terminal 32b. Reply. It should be noted that the usage conditions are the number of times "5" and the time "01:20" as indicated by the arrow Y16.

In step S24, the access unit 45b makes a registration request for the own terminal device to the terminal management unit 48 of the keystore 33 by the user name. At this time, in step S25, the access unit 45b transmits the terminal key (public) K3b with the returned signature and usage conditions to the terminal management unit 48.

In step S26, the terminal management unit 48 refers to the terminal management table T1 (FIG. 3) stored in the access control unit 47, and searches for the terminal key (public) K3a of the registered terminal 32a. In step S27, the terminal management unit 48 verifies the signed and usage condition-attached terminal key (public) K3b transmitted in step S25 with the searched terminal key (public) K3a. .. If this verification is OK, the terminal management unit 48 registers a new second terminal 32b in the access management unit 47 in step S28.

For this registration, the first user is in the user column of the terminal management table T1 in FIG. 3, the second terminal (Dev-2) is in the terminal ID column, and the terminal key (public) K3b "62C8F27DD ..." is in the public key column. The information column is the trust information (first terminal), the usage condition column is the remaining number of times "5", and the remaining time is "01:20". The remaining number of times "5" indicates that the number of times the service has been used is five. The remaining time "01:20" indicates that the service usage time is 1 hour and 20 minutes. As for the terms of use, the keystore operator may set individual terms of use.

<Authentication key registration process of the first embodiment>
Next, FIG. 7 shows a process of generating an authentication key (secret) (for example, authentication key (secret) K4a) on the key store 33 and newly registering the authentication key (public) K1a in the server (for example, server 31a). This will be described in detail with reference to the sequence diagram.

When the registration process of the authentication key (secret) based on FIDO is started, the terminal accesses the keystore based on the challenge-response authentication using the terminal key. In this example, only the registered terminal 32a registered based on the identity verification information can generate a new authentication key in the keystore 33.

In step S31, since the registered terminal 32a wants to use the service of the server (for example, server 31a), it is assumed that the Web client 43a requests the authentication unit 41a of the server 31a to use the authentication key in step S31. .. In step S32, the authentication unit 41a searches the policy management table T3 stored in the authentication unit 41a for a usage policy (also referred to as a policy) corresponding to the service related to the registration request. In the policy management table T3, policies are associated and stored for each service.

In step S33, the authentication unit 41a transmits the authentication key registration request and the policy searched in step S32 to the access unit 45a of the registered terminal 32a. In step S34, the access unit 45a makes a registration connection request to the terminal management unit 48 of the keystore 33. Upon receiving this request, the terminal management unit 48 transmits a terminal identification challenge, which is a random character string for terminal identification, to the access unit 45a of the registered terminal 32a in step S35.

In step S36, the access unit 45a notifies the terminal key management unit 46a that it has received the terminal identification challenge. Upon receiving this notification, the terminal key management unit 46a performs biometric authentication in step S37, and if the result is OK, signs the terminal identification challenge with the terminal key (secret) K2a and accesses in step S39. Return to section 45. Upon receiving this, the access unit 45a transmits the signed challenge to the terminal management unit 48 of the keystore 33 in step S40.

In step S41, the terminal management unit 48 refers to the terminal management table T1 shown in FIG. 3 stored in the access control unit 47, and in step S42, the terminal 32a that has made the registration request is registered with the identity verification information. Verify with the terminal key (public) K3a of the terminal 32a. That is, the above signed challenge is verified with the terminal key (public) K3a "D23094F1F ..." registered in the public key field. If this verification is OK, the terminal management unit 48 transmits the connection OK to the server 31a to the access unit 45 of the registered terminal 32a in step S43.

In step S44, the access unit 45a transmits the authentication key registration request and the above policy to the authentication key management unit 49 of the keystore 33. In step S45, the authentication key management unit 49 generates a key pair of the authentication key (secret) K4a and the authentication key (public) K1a, and holds the authentication key (secret) K4a. Further, in step S46, the authentication key management unit 49 transmits the authentication key (public) K1a to the access unit 45 of the registered terminal 32a. In step S47, the access unit 45a requests the authentication unit 41a of the server 31a to register the authentication key (public) K1a.

The authentication unit 41a holds the authentication key (public) K1a in step S48. In the key management table T4 stored in the authentication unit 41a, the authentication key (public) K1a "62C951BA2F ..." is registered as the authentication key in the account "User1" of the registered terminal 32a. Will be. After this registration, the authentication unit 41a transmits the registration completion to the Web client 43 of the registered terminal 32a in step S49.

<User authentication process when using the service of the first embodiment>
Next, refer to the sequence diagram shown in FIG. 8 for the process of performing user authentication for using the service of the server 31a using the authentication key (secret) K4a registered in the keystore 33 as described above. Will be explained concretely.

First, the main points of the user authentication process will be described. When the authentication process based on FIDO is started, the registered terminal 32a accesses the keystore based on the challenge-response authentication using the terminal key. After that, the authentication challenge, which is a random character string related to the service used received from the server 31a, is transferred to the key store 33, and a signature with the terminal key (secret) associated with the specified key ID (service-specific ID) is requested. .. Here, the keystore 33 uses the authentication key by matching the usage conditions managed in association with the registered terminal 32a being accessed with the usage policy associated with the designated key. Judge whether it is possible or not. Only when it is determined that the authentication key can be used, the keystore 33 signs the authentication challenge and returns it to the registered terminal 32a as a response. The registered terminal 32a completes the authentication process by transferring the signed authentication challenge as the returned response to the server 31a. A detailed description of this authentication process will be given with reference to FIG.

In step S51 shown in FIG. 8, it is assumed that the Web client 43 of the registered terminal 32a makes a user authentication request for using the service of the server 31a to the authentication unit 41a of the server 31a. In step S52, the authentication unit 41a searches the service-specific ID table T5 held by the authentication unit 41a for the key ID “service2.jp” unique to the service. Next, in step S53, the authentication unit 41a transmits an authentication challenge including the searched key ID to the access unit 45a of the registered terminal 32a.

In step S54, the access unit 45a makes an authentication connection request to the terminal management unit 48 of the keystore 33. In step S55, the terminal management unit 48 that has received this request transmits a terminal identification challenge, which is a character string for identifying the terminal, to the access unit 45a of the registered terminal 32a.

In step S56, the access unit 45a notifies the terminal key management unit 46a that it has received the terminal identification challenge. Upon receiving this notification, the terminal key management unit 46a performs biometric authentication in step S57, and if the result is OK, signs the terminal identification challenge with the terminal key (secret) K2a and accesses in step S59. Return to section 45. Upon receiving this, the access unit 45a transmits the signed challenge as a response to the terminal management unit 48 of the keystore 33 in step S60.

In step S61, the terminal management unit 48 referred to the terminal management table T1 shown in FIG. 3 stored in the access control unit 47, and registered the terminal 32a for which the authentication request was made with the identity verification information in step S62. The terminal key (public) K3a of the terminal 32a is used to verify whether or not it is appropriate. That is, the above signed challenge is verified with the terminal key (public) K3a "D23094F1F ..." registered in the public key field. If this verification is OK, the terminal management unit 48 transmits the connection OK to the server 31a to the access unit 45 of the registered terminal 32a in step S63.

In step S64, the access unit 45a transmits an authentication challenge including the key ID received in step S53 to the authentication key management unit 49 of the keystore 33. That is, in the authentication challenge related to the service used received from the server 31a, the authentication key management unit 49 is requested to sign with the terminal key (secret) K2a associated with the designated key ID.

In response to this request, the authentication key management unit 49 determines in step S65 whether or not the authentication key can be used with reference to the terminal management table T1 (FIG. 3) and the key management table T2 (FIG. 4). This determination will be described with reference to FIGS. 3 and 4. The authentication key management unit 49 manages the terminal management table T1 shown in FIG. 3 in association with the registered terminal 32a "terminal ID = first terminal 32a (Dev-1)" being accessed. The condition "none" is matched with the usage policy (confirmation at the time of registration "trust information", frequency "unlimited") associated with the specified key ID "service2.jp" in the key management table T2 shown in FIG. By doing so, it is judged whether or not the authentication key can be used.

Here, when it is determined that the authentication key may be used, the authentication key management unit 49 signs the authentication challenge in step S66, and the signed authentication challenge is performed in step S67 by the registered terminal 32a. It transmits to the server 31a via the access unit 45a of the above. In step S68, the server 31a verifies the signed authentication challenge with the authentication key (public) K1a, and if the verification is OK, notifies the Web client 43 of the registered terminal 32a in step S69 that the authentication is complete.

In the sequence operation of FIG. 8, the authentication operation on the registered terminal 32a based on the identity verification information has been described, but the same can be performed on the terminal 32b based on the trust information. However, in the case of the terminal 32b based on the trust information, since the restriction is registered in the usage policy of the key management table T2 in the determination of whether or not the authentication key can be used in step S62, the services of the servers 31a and 31b are within the usage restriction. Will be available. Further, in the determination of whether or not to use the authentication key in step S65, if the use of the authentication key is "No", the terminal 32a is notified of the error so that the user can recognize it.

<Effect of the first embodiment>
As described above, the authentication key sharing system 30A of the first embodiment has the following characteristic configuration. The system 30A includes servers 31a and 31b that provide various services by communication, and terminals 32a and 32b that use the services by communication. Further, the system 30A has an authentication key (public) K1a, K1b as a public key for authenticating the service and an authentication key (secret) K4a, as a private key for service authentication paired with the authentication keys (public) K1a, K1b. Key store 33 in which K4b and terminal keys (public) K3a and K3b as public keys paired with terminal keys (secret) K2a and K2b held by terminals 32a and 32b as private keys are registered. And have.

(1) The terminals 32a and 32b present the identity verification information guaranteed by a third party, and store the terminal key (secret) K2a and the terminal key (public) K3a held by the self-registered terminal 32a. When the registered terminal 32a registered in 33 exists, the terminal key (secret) K2b and the paired terminal key (public) K3b held in the newly registered new terminal 32b are used for the registered terminal 32a. It is provided with terminal key management units 46a and 46b that sign with the terminal key (secret) K2a held by the user and transmit the signed terminal key (public) generated by this signature to the key store 33.

The keystore 33 is the terminal key of the new terminal 32b when the signature of the signed terminal key (public) is verified by the terminal key (public) K3a of the registered terminal 32a held in the keystore 33. (Public) K3b is configured to include a terminal management unit 48 for registering the key store 33.

According to this configuration, the terminal key (public) K3b of the new terminal 32b is signed with the terminal key (secret) K2a of the registered terminal 32a, and the signed terminal key (public) is authenticated by the key store 33. The terminal key (public) K3b of the new terminal 32b can be registered. Therefore, when registering the new terminal 32b in the key store 33, it is possible to easily authenticate and register without presenting the identity verification information.

Therefore, if the number of terminals owned, including wearable terminals, increases dramatically in the future, or if shared terminals existing in various locations are temporarily occupied and the service is used, at the end of use. When the usage style of releasing is generalized, the new terminal can be easily authenticated and registered in the keystore 33 to use the services of the servers 31a and 31b.

(2) The terminal key management units 46a and 46b of the terminals 32a and 32b transmit the signed terminal key (public) to the keystore 33 with usage conditions for restricting the use of the service. When the terminal key (public) K3b of the new terminal 32b is registered, the terminal management unit 48 of the key store 33 registers the usage conditions in association with each other, and the registered usage conditions are used to provide the service of the new terminal 32b. The use of authentication keys (secret) K4a and K4b for use is restricted. In other words, when the registered terminal 32a sends the usage conditions that restrict the use of the service to the new terminal 32b and the terminal key (public) K3b is registered in the keystore 33 of the new terminal 32b, the usage conditions are set. It is transmitted to the keystore 33, and the keystore 33 restricts the use of the service of the new terminal 32b according to the usage conditions.

According to this configuration, the following effects can be obtained. In the new terminal 32b registered by authentication based on the signature between the terminals 32a and 32b, the use of the service should be restricted to differentiate it from the registered terminal 32a registered by presenting the identity verification information. Can be done.

(3) In the terminals 32a and 32b, both the new terminal 32b and the registered terminal 32a are predetermined before the new terminal 32b and the registered terminal 32a perform communication for signing. The configuration is further provided with mutual confirmation units 44a and 44b for establishing communication between the two when predetermined operations are performed simultaneously at a distance.

According to this configuration, communication between the terminals 32a and 32b is performed only when the terminals 32a and 32b are simultaneously performed with the predetermined operations within a predetermined distance, for example, within 2 m. Therefore, it is possible to improve the convenience of the user who uses the terminals 32a and 32b without deteriorating the security.

(4) The terminals 32a and 32b associate the personal identification information with the registered terminal 32a registered in the key store 33 by presenting the personal identification information, and sign between the registered terminal 32a and the new terminal 32b. The new terminal 32b, whose signature of the generated signed terminal key (public) is verified and registered in the key store 33, is provided with an access control unit 47 that associates the trust information with the terminal management table T1 and stores it in the terminal management table T1. did.

According to this configuration, in the terminal management table T1 of the keystore 33, the registered terminal 32a is associated with the identity verification information, and the new terminal 32b is associated with the trust information. As a result, whether the terminals 32a and 32b registered in the keystore 33 are authenticated by the identity verification information or the signatures between the terminals 32a and 32b are easily authenticated. It can be easily identified. Therefore, it can be accurately identified when the usage conditions are attached to the terminals 32a and 32b.

<Structure of the second embodiment>
Next, the authentication key sharing system according to the second embodiment will be described with reference to the authentication key sharing system 30B shown in FIG. However, in the system 30B, the same parts as those of the authentication key sharing system 30A of the first embodiment shown in FIG. 2 are designated by the same reference numerals, and the description thereof will be omitted as appropriate.

The difference between the system 30B shown in FIG. 9 and the system 30A is that the challenge is used for mutual confirmation between the terminals 32a and 32b. Further, in the system 30B, the terminals 32a and 32b of each other are in a state where proximity communication is established at a predetermined distance.

The terminal identification challenge (described as chal in FIG. 9) 51 received from the keystore 33 by the new terminal 32b as shown by the arrow Y21 is registered by the proximity communication as shown by the arrow Y22. And request a signature with the terminal key (secret) K2a. In response to this request, the registered terminal 32a signs the terminal identification challenge 51 with the terminal key (secret) K2a, and the signed terminal identification challenge 51A as this response is a new terminal as shown by the arrow Y23. Reply to 32b.

The new terminal 32b generates a terminal key (secret) K2b and a terminal key (public) K3b using the returned signed terminal identification challenge 51A as trust information, and transfers the terminal key (secret) K2b to the terminal key management unit 46b. The terminal key (public) K3b is held and transmitted together with the signed terminal identification challenge 51A to the key store 33 as shown by the arrow Y24. When the key store 33 receives the trust information of the signed terminal identification challenge 51A, the key store 33 registers the terminal key (public) K3b in the terminal management unit 48. As a result, the new terminal 32b is newly registered in the keystore 33. At the time of this new registration, the usage conditions may be set in the same manner as in the system 30A described above.

Further, as shown by the arrow Y3A, the servers 31a and 31b have the authentication keys (public) K1a and K1b and the authentication keys (secret) K4a and K4b held by the authentication units 41a and 41b of the own servers 31a and 31b. It can be held in the authentication key management unit 49 of the key store 33. The key store 33 can access the services associated with the authentication keys (public) K1a and K1b of the servers 31a and 31b as indicated by the arrows Y4A with the authentication keys (secret) K4a and K4b.

<Terminal registration process using the trust information of the second embodiment>
The process of newly registering the second terminal 32b in the keystore 33 by utilizing the trust information of the registered terminal 32a described above will be specifically described with reference to the sequence diagram shown in FIG.

In step S71 shown in FIG. 10, the access unit 45b of the second terminal 32b for new registration makes a terminal registration connection request to the access management unit 47 of the keystore 33. In response to this request, the access management unit 47 transmits the terminal identification challenge 51 (see FIG. 9) to the mutual confirmation unit 44b via the access unit 45b of the second terminal 32b in step S72.

In step S73, the mutual confirmation unit 44b makes a proximity communication establishment request to the mutual confirmation unit 44a of the registered first terminal 32a. In step S74, the mutual confirmation unit 44a that has received the proximity communication establishment request displays a connection code to be shown to the user on the display (not shown) of the first terminal 32a. The user who sees the connection code displayed on the display inputs the connection code to the mutual confirmation unit 44b of the second terminal 32b in step S75.

In step S76, the mutual confirmation unit 44b transmits the connection code to the mutual confirmation unit 44a of the first terminal 32a. Upon receiving this connection code, the mutual confirmation unit 44a makes a proximity communication establishment response to the mutual confirmation unit 44b of the second terminal 32b in step S77. After this response, the access unit 45b transmits the terminal identification challenge 51 received from the key store 33 to the terminal key management unit 46a of the first terminal machine 32a in step S78.

In the registered first terminal 32a, in step S79, the usage conditions (number of times of service use, time, etc.) of the second terminal 32b that the user newly registers are specified. After this designation, the terminal key management unit 46a performs biometric authentication in step S80. If the biometric authentication is OK, in step S81, the terminal key management unit 46a signs the terminal identification challenge 51 with the terminal key (secret) K2a held by the own terminal key management unit 46a. With this signature, a signed terminal identification challenge 51A (see FIG. 9) as a response is generated, and the usage conditions specified in step S79 are added to the challenge. As shown by the arrow Y17, this usage condition is assumed to be the number of times the service is used "5" and the time "01:20". In step S82, the signed terminal identification challenge 51A to which the usage conditions are added is transmitted from the terminal key management unit 46a to the access unit 45b of the second terminal 32b.

In step S83, the access unit 45b transmits the signed terminal identification challenge 51A to which the usage conditions are added to the terminal management unit 48 of the keystore 33. In step S84, the terminal management unit 48 refers to the terminal management table T1 stored in the access control unit 47, and searches for the terminal key (public) K3a of the registered terminal machine 32a. In step S85, the terminal management unit 48 verifies the signed terminal identification challenge 51A to which the usage conditions are added in step S85 with the searched terminal key (public) K3a. If this verification is OK, in step S86, the connection OK is transmitted to the terminal key management unit 46b via the access unit 45b of the second terminal machine 32b. The user of the second terminal 32b who received this connection OK operates the biometric authentication.

In response to this operation, the terminal key management unit 46b performs biometric authentication in step S87. If the biometric authentication is OK, the terminal key management unit 46b generates a pair of terminal key (secret) K2b and terminal key (public) K3b in step S88. Further, the terminal key management unit 46b holds the generated terminal key (secret) K2b in step S89 (FIG. 2), and inputs the terminal key (public) K3b to the access unit 45b in step S90.

In step S91, the access unit 45 makes a registration request for the terminal 32b by the user name to the terminal management unit 48 of the key store 33. At this time, in step S92, the access unit 45b transmits the terminal key (public) K3b input in step S90 to the terminal management unit 48 of the keystore 33 together with the usage conditions received in step S82.

In step S93, the terminal management unit 48 registers a new second terminal 32b by registering the terminal key (public) K3b together with the usage conditions in the terminal management table T1 of the access management unit 47. This registration is performed by the first user in the user column of the terminal management table T1 in FIG. 3, the second terminal (Dev-2) in the terminal ID column, and "62C8F27DD ..." as the terminal key (public) K3b in the public key column. The information column at the time of registration is the trust information (first terminal), the remaining number of times is "5", and the remaining time is "01:20" in the usage condition column. As for the terms of use, the keystore operator may set individual terms of use.

<Effect of the second embodiment>
As described above, the authentication key sharing system 30B of the second embodiment has the following characteristic configuration. The system 30B includes servers 31a and 31b that provide various services by communication, and terminals 32a and 32b that use the services by communication. Further, the system 30B has an authentication key (public) K1a, K1b as a public key for authenticating the service and an authentication key (secret) K4a, as a private key for service authentication paired with the authentication keys (public) K1a, K1b. Key store 33 in which K4b and terminal keys (public) K3a and K3b as public keys paired with terminal keys (secret) K2a and K2b held by terminals 32a and 32b as private keys are registered. And have.

(1) The terminals 32a and 32b present the identity verification information guaranteed by a third party, and store the terminal key (secret) K2a and the terminal key (public) K3a held by the registered terminal 32a in the key store 33. When the registered terminal 32a registered in the above exists, the newly registered new terminal 32b takes the registered terminal to the terminal identification challenge by a random character string for identifying the terminal received from the key store. It is provided with a terminal key management unit 46a that signs with the terminal key (secret) K2a held by 32a and returns a signed terminal identification challenge as a response generated by this signature to the key store 33.

In the keystore 33, when the signature of the signed terminal identification challenge is verified by the terminal key (public) K3a of the registered terminal 32a held in the keystore 33, the terminal key (public) of the new terminal 32b is verified. ) K3b is configured to include a terminal management unit 48 for registering the keystore 33.

According to this configuration, the terminal identification challenge from the new terminal 32b is signed with the terminal key (secret) K2a of the registered terminal 32a, and this signed terminal identification challenge is authenticated by the key store 33 to be the new terminal. The terminal key (public) K3b of 32b can be registered. Therefore, when registering the new terminal 32b in the key store 33, it is possible to easily authenticate and register without presenting the identity verification information.

(2) The terminal key management units 46a and 46b of the terminals 32a and 32b transmit the signed terminal identification challenge to the keystore 33 with usage conditions that restrict the use of the service. When the terminal key (public) K3b of the new terminal 32b is registered, the terminal management unit 48 of the key store 33 registers the usage conditions in association with each other, and the registered usage conditions are used to provide the service of the new terminal 32b. The use of authentication keys (secret) K4a and K4b for use is restricted. In other words, when the registered terminal 32a sends the usage conditions that restrict the use of the service to the new terminal 32b and the terminal key (public) K3b is registered in the keystore 33 of the new terminal 32b, the usage conditions are set. It is transmitted to the keystore 33, and the keystore 33 restricts the use of the service of the new terminal 32b according to the usage conditions.

According to this configuration, the following effects can be obtained. The new terminal 32b registered by the authentication based on the signature between the terminals 32a and 32b does not present the identity verification information guaranteed by a third party, and the reliability of the authentication is low. Therefore, it is possible to set restrictions on the use of the service of the new terminal 32b and differentiate it from the registered terminal 32a registered by presenting the identity verification information.

<Structure of the third embodiment>
FIG. 11 is a block diagram showing a configuration of the authentication key sharing system 30C according to the third embodiment of the present invention. However, in the system 30C, the same parts as those of the authentication key sharing system 30A shown in FIG. 2 are designated by the same reference numerals, and the description thereof will be omitted as appropriate.

The system 30C shown in FIG. 11 differs from the system 30A in that the servers 51a and 51b are provided with authentication key usage control units 52a and 52b, and the servers 51a and 51b determine whether or not the authentication key can be used for the terminals 32a and 32b. I have done so. The keystore 33 manages identity verification information and trust information. Further, when the terminals 32a and 32b use the authentication keys (secret) K4a and K4b, the key store 33 transmits the information at the time of registration of the terminals 32a and 32b to the servers 51a and 51b as indicated by the arrows Y32. To do. The authentication key usage control units 52a and 52b of the servers 51a and 51b confirm the transmitted information at the time of registration and decide whether or not to use the service on the terminals 32a and 32b.

Further explaining, the keystore 33 does not store the usage conditions for each of the terminals 32a and 32b, but the keystore 33 stores the information at the time of registration in association with the terminals 32a and 32b. The information at the time of registration is performed as an example shown in the terminal management table T1 of FIG. In the line of the first terminal 32a (Dev-1), the identity verification information is registered in the confirmation information column, and 10:42 on January 1, 2017 (2017/1/1/10: 42) is registered in the registration date and time column. To. In the line of the second terminal 32b (Dev-2), the trust information is registered in the confirmation information column, and 12:12 (2017/4/1/12: 12) on April 1, 2017 is registered in the registration date and time column. ..

When the terminals 32a and 32b access the keystore 33 and perform user authentication (challenge-response method) using the authentication keys (secret) K4a and K4b as shown by the arrow Y31, the authentication destination server 51a, For the service of 51b, the information at the time of the above registration of the corresponding terminals 32a and 32b is added to the response to the authentication challenge and sent. However, the arrow Y31 also indicates the registration of the authentication key between the servers 51a and 51b and the keystore 33.

On the server 51a, 51b side, the information at the time of registration of the assigned terminals 32a, 32b is referred to, and the user authentication request from the corresponding terminals 32a, 32b is arbitrarily restricted. As an example of this limitation, the request of the terminal 32b registered with the trust information is rejected. Alternatively, the trust information of the terminal 32b is allowed only for a certain period after registration, the number of times of use per unit time is limited, and the like.

However, in the system 10A (FIG. 2) of the first embodiment, the usage conditions can be specified by the user who executes the registration process of the new terminal at the time of mutual confirmation. However, in the system 30C of the third embodiment, it is impossible for the user to specify the usage conditions by himself / herself.

<Terminal registration process using the trust information of the third embodiment>
In the system 30C of the third embodiment, the process of registering the second terminal 32b in the keystore 33 by utilizing the trust information of the registered terminal 32a will be specifically described with reference to the sequence diagram shown in FIG. To do. However, in FIG. 12, the same steps as those in the sequence diagram shown in FIG. 6 of the first embodiment are designated by the same reference numerals, and the description thereof will be omitted as appropriate. Further, in the system 30C, unlike the system 10A, the key usage conditions for each of the terminals 32a and 32b are not stored in the terminal management table T1, but the information at the time of registration of the terminals 32a and 32b is stored in the key store 33. It shall be left.

The processes from steps S11 to S22 shown in FIG. 12 are the same as those in FIG. In the final step S22 of these processes, the terminal key management unit 46a of the registered terminal 32a uses the terminal key (secret) K2a of the own terminal 32a to receive the terminal from the second terminal 32b to be newly registered. Sign the key (public) K3b.

After that, in the system 30C of the third embodiment, in step S23A, the terminal key management unit 46a transmits the signed terminal key (public) K3b as a response via the terminal key management unit 46b of the second terminal machine 32b. Reply to the access unit 45b.

In step S24A, the access unit 45b makes a registration request for its own terminal to the terminal management unit 48 of the keystore 33 according to the user name. At this time, the access unit 45b transmits the signed terminal key (public) K3b to the terminal management unit 48 in step S25A.

In step S26, the terminal management unit 48 refers to the terminal management table T1 stored in the access management unit 47, and searches for the terminal key (public) K3a of the registered terminal machine 32a. In step S27A, the terminal management unit 48 verifies the signed terminal key (public) K3b transmitted in step S25A with the searched terminal key (public) K3a. If this verification is OK, the terminal management unit 48 registers a new second terminal 32b in the access management unit 47 in step S28A. This registration is performed by registering the terminal key (public) "62C8F27DD ..." in the public key column and the trust information in the confirmation information column in the row of the second terminal 32b (Dev-2) of the terminal management table T1 shown in FIG. 12:12 on April 1, 2017 (2017/4/1/12: 12) is registered in the date and time column.

<Authentication key registration process of the third embodiment>
Next, FIG. 13 shows a process of generating an authentication key (secret) (for example, authentication key (secret) K4a) on the key store 33 and newly registering the authentication key (public) K1a in the server (for example, server 51a). This will be described in detail with reference to the sequence diagram. However, in FIG. 13, the same steps as those in the sequence diagram shown in FIG. 7 of the first embodiment are designated by the same reference numerals, and the description thereof will be omitted as appropriate. Further, unlike the system 30A of the first embodiment, the system 30C does not have information on the policy regarding the use of the corresponding authentication keys (public) K1a and K1b on the servers 51a and 51b side, and each authentication key is also on the keystore 33 side. (Secret) The terms of use of K4a and K4b shall not be managed.

In FIG. 13, since the registered terminal 32a wants to use the service of the server (for example, the server 51a), it is assumed that in step S31, the Web client 43a makes a registration request to the authentication unit 41a of the server 51a to use the authentication key. .. In step S32, the authentication unit 41a searches the service-specific ID table T5 stored in the authentication unit 41a for the authentication key (public) K1a related to the registration request.

In step S33A, the authentication unit 41a transmits a registration request for the authentication key to the access unit 45a of the registered terminal 32a based on the searched authentication key (public) K1a. Subsequent processes in steps S34 to S43 are the same as in FIG. 7. In the final step S43 of these processes, the terminal management unit 48 of the keystore 33 transmits the connection OK to the server 51a to the access unit 45a of the registered terminal 32a.

In step S44A, the access unit 45a transmits the authentication key registration request to the authentication key management unit 49 of the keystore 33. In step S45, the authentication key management unit 49 generates a key pair of the authentication key (secret) K4a and the authentication key (public) K1a, and holds the authentication key (secret) K4a. Further, in step S46, the authentication key management unit 49 transmits the authentication key (public) K1a to the access unit 45a of the registered terminal 32a. In step S47, the access unit 45a requests the authentication unit 41a of the server 51a to register the authentication key (public) K1a.

The authentication unit 41a holds the authentication key (public) K1a in step S48. In the key management table T4 stored in the authentication unit 41a, the authentication key (public) K1a "62C951BA2F ..." is registered as the authentication key in the account "User1" of the registered terminal 32a. Will be. After this registration, the authentication unit 41a transmits the registration completion to the Web client 43 of the registered terminal 32a in step S49.

<User authentication process when using the service of the third embodiment>
Next, FIG. 14 shows a process of performing user authentication for using the services of the servers 51a and 51b by using the authentication key (secret) K4a registered in the keystore 33 as shown in FIG. 13 described above. This will be described in detail with reference to the sequence diagram.

Unlike the system 30A of the first embodiment, the system 30C of the third embodiment does not control the availability of the authentication keys (secret) K4a and K4b stored in the keystore 33, and from which terminals 32a and 32b Even if it is a request of, it shall be signed. However, by adding the information at the time of registration of the accessing terminal (for example, terminal 32b) to the signed authentication challenge as a response and returning it to the server (for example, server 51a), the server 51a side at the time of registration Even if the signature is correct, it is possible to confirm whether or not to accept the authentication request from the terminal 32b.

In step S51A shown in FIG. 14, it is assumed that the Web client 43b of the terminal 32b registered by the trust information makes an authentication request for the user to use the service of the server to the authentication unit 41a of the server 51a. In step S52, the authentication unit 41a searches the service-specific ID table T5 held by the self-authentication unit 41a for the key ID “service2.jp” unique to the service. Next, in step S53A, the authentication unit 41a transmits an authentication challenge including the searched key ID to the access unit 45 of the terminal 32b.

In step S54A, the access unit 45b makes an authentication connection request to the terminal management unit 48 of the keystore 33. Upon receiving this request, the terminal management unit 48 transmits the terminal identification challenge to the access unit 45b of the terminal 32b in step S55A.

In step S56A, the access unit 45b notifies the terminal key management unit 46b that it has received the terminal identification challenge. Upon receiving this notification, the terminal key management unit 46b performs biometric authentication in step S57A, and if the result is OK, signs the terminal identification challenge with the terminal key (secret) K2b and accesses in step S59A. Return to unit 45b. Upon receiving this, the access unit 45b transmits a signed challenge as a response to the terminal management unit 48 of the keystore 33 in step S60A.

In step S61A, the terminal management unit 48 refers to the terminal management table T1 (FIG. 11) stored in the access control unit 47, and in step S62A, the terminal 32b that made the authentication request is registered with the identity verification information. Verify with the terminal key (public) K3b of the terminal 32b. That is, in Dev-2 of the terminal ID column of the terminal management table T1 of FIG. 11, the above-mentioned signed challenge is verified by the terminal key (public) K3b "62C8F27DD ..." registered in the public key column. If this verification is OK, the terminal management unit 48 transmits the connection OK to the server 51a to the access unit 45b of the terminal 32b in step S63A.

In step S64A, the access unit 45b shown in FIG. 14 transmits an authentication challenge including the key ID to the authentication key management unit 49 of the keystore 33. That is, in the authentication challenge received from the server 51a, the authentication key management unit 49 is requested to sign with the authentication key (secret) K4a associated with the designated key ID.

In response to this request, the authentication key management unit 49 signs the authentication challenge in step S66A. It should be noted that, between steps S64A and S66A in FIG. 14, there is a process for determining whether or not the authentication key in step S65 can be used in FIG. 8, but the process for determining whether or not the authentication key can be used is not executed in FIG. ..

In step S67A of FIG. 14, a signed authentication challenge as a response obtained by the signature of step S66A is transmitted to the access unit 45a of the registered terminal 32b. The access unit 45b adds the information at the time of registration to the signed authentication challenge and transmits it to the authentication unit 41a of the server 51a in step S67B.

In step S101, the authentication unit 41a outputs the transmitted information at the time of registration to the authentication key usage control unit 52a. In step S102, the authentication key use control unit 52a determines whether or not the service can be used from the information at the time of registration. If this determination is "No", the terminal 32b is notified of the error so that the user can recognize it. On the other hand, if the determination is OK, the service usage OK is output from the authentication key usage control unit 52a to the authentication unit 41a in step S103. In step S104, the authentication unit 41a verifies the signed authentication challenge received in step S67B with the authentication key (public) K1a registered in the key management table T4. If this verification is OK, in step S105, the authentication unit 41a notifies the Web client 43b of the terminal 32b of the completion of the authentication.

In the sequence operation of FIG. 14, the process in which the terminal 32b related to the trust information performs user authentication for using the service of the server 51a has been described, but in the terminal 32a where there is no restriction on the service use based on the identity verification information. Can be done in the same way.

<Effect of the third embodiment>
As described above, the authentication key sharing system 30C of the third embodiment has the following characteristic configuration. The system 30C includes servers 51a and 51b that provide various services by communication, and terminals 32a and 32b that use the services by communication. Further, the system 30C has an authentication key (public) K1a, K1b as a public key for authenticating the service and an authentication key (secret) K4a, as a private key for service authentication paired with the authentication keys (public) K1a, K1b. Key store 33 in which K4b and terminal keys (public) K3a and K3b as public keys paired with terminal keys (secret) K2a and K2b held by terminals 32a and 32b as private keys are registered. And have.

(1) An access control unit that stores information at the time of registration of terminals 32a and 32b related to the registered terminal 32a and the new terminal 32b in the keystore 33 in association with the unique information of the terminals 32a and 32b. It was equipped with 47. When the terminals 32a and 32b use the authentication keys (secret) K4a and K4b registered in the keystore 33, the servers 51a and 51b use the information at the time of registration of the terminals 32a and 32b received from the keystore. Correspondingly, the configuration is configured to include authentication key utilization control units 52a and 52b that restrict the use of the authentication keys (secret) K4a and K4b of the terminals 32a and 32b.

According to this configuration, the servers 51a and 51b restrict the use of the authentication keys (secret) K4a and K4b of the terminals 32a and 32b according to the information at the time of registration of the terminals 32a and 32b. The use of the service for 32a and 32b can be restricted.

In addition, the specific configuration can be appropriately changed without departing from the gist of the present invention.

30,30A, 30B, 30C Authentication key sharing system 31a, 31b, 51a, 51b Web server (server)
32a, 32b Terminal 33 Key store 41a, 41b Authentication unit 43a, 43b Web client 45a, 45b Key store access unit 46a, 46b Terminal key management unit 43a, 43b Web client 44a, 44b Mutual confirmation unit 47 Access management unit 48 Terminal management Department 49 Authentication key management unit 52a, 52b Authentication key usage control unit T1 Terminal management table K1a, K1b Authentication key (public)
K2a, K2b terminal key (secret)
K3a, K3b terminal key (public)
K4a, K4b authentication key (secret)

Claims (8)

For service authentication paired with a server that provides various services by communication, a terminal that uses the service for communication, an authentication key (public) as a public key that authenticates the service, and the authentication key (public). An authentication key (secret) as a private key and a key store in which a terminal key (secret) as a private key for a terminal held by the terminal and a terminal key (public) as a pair of public keys are registered. It is an authentication key sharing system that has
The terminal is
When there is a registered terminal that presents identity verification information guaranteed by a third party and registers the terminal key (secret) and the paired terminal key (public) held by the self-registered terminal in the key store. , The terminal key (secret) held in the new terminal to be newly registered and the paired terminal key (public) are signed with the terminal key (secret) held by the registered terminal, and generated by this signature. It is equipped with a terminal key management unit that sends a signed terminal key (public) to the key store.
In the keystore, when the signature of the signed terminal key (public) is verified by the terminal key (public) of the registered terminal held in the keystore, the terminal key (public) of the new terminal is used. ) Is provided in the terminal management department to register in the keystore .
The registered terminal transmits the usage conditions for restricting the use of the service to the new terminal.
When the terminal key (public) of the new terminal is registered in the keystore, the terms of use are transmitted to the keystore.
The key store is an authentication key sharing system characterized in that the use of the service of the new terminal is restricted according to the usage conditions . For service authentication paired with a server that provides various services by communication, a terminal that uses the service for communication, an authentication key (public) as a public key that authenticates the service, and the authentication key (public). An authentication key (secret) as a private key and a key store in which a terminal key (secret) as a private key for a terminal held by the terminal and a terminal key (public) as a pair of public keys are registered. It is an authentication key sharing system that has
The terminal is
When there is a registered terminal that presents identity verification information guaranteed by a third party and registers the terminal key (secret) and the paired terminal key (public) held by the self-registered terminal in the key store. In response to a connection request for a new terminal to be newly registered, the registered terminal obtained from the new terminal takes a terminal identification challenge using a random character string for identifying the terminal received from the key store. , signed with a terminal key (secret) which the registered terminal is held, with a terminal key management unit the signed terminal identification challenge generated by the signature returns to the key store through the new terminal,
The keystore uses the terminal key (public) of the new terminal when the signature of the signed terminal identification challenge is verified with the terminal key (public) of the registered terminal held in the keystore. includes a terminal management unit for registering to the key store,
The registered terminal transmits the usage conditions for restricting the use of the service to the new terminal.
When the terminal key (public) of the new terminal is registered in the keystore, the terms of use are transmitted to the keystore.
The key store is an authentication key sharing system characterized in that the use of the service of the new terminal is restricted according to the usage conditions . When transmitting the terms of use from the registered terminal to the new terminal, the signature is signed with the terminal key (secret) held by the registered terminal, and the signed terminal key (public ) generated by this signature. authentication key sharing system according to claim 1, characterized in that transmits with the use conditions. From said registered terminal when transmitting the use condition to the new terminal, signed with a terminal key (secret) which the registered terminal is held, the signed terminal identification challenge generated by the signature of this The authentication key sharing system according to claim 2 , wherein the transmission is performed with the terms of use. The key store is provided with an access control unit that stores information at the time of registration of the registered terminal and the terminal related to the new terminal in association with the unique information of the terminal.
When the server uses the authentication key (secret) registered in the keystore, the server authenticates the terminal according to the information at the time of registration of the terminal received from the keystore. The authentication key sharing system according to claim 1 or 2, further comprising an authentication key usage control unit that restricts the use of a key (secret). The terminal is
Before the communication for the signature is performed between the new terminal and the registered terminal, both the new terminal and the registered terminal perform a predetermined operation at a predetermined distance. The authentication key sharing system according to any one of claims 1 to 5, further comprising a mutual confirmation unit that establishes communication between the two when performed at the same time. The keystore is
By presenting the identity verification information, the identity verification information is associated with the registered terminal registered in the key store, and the signed terminal key generated by the signature between the registered terminal and the new terminal ( Any of claims 1 to 6, wherein the new terminal whose signature of (public) is verified and registered in the key store is provided with an access control unit for associating trust information and storing it in a terminal management table. The authentication key sharing system described in item 1. For service authentication paired with a server that provides various services by communication, a terminal that uses the service for communication, an authentication key (public) as a public key that authenticates the service, and the authentication key (public). An authentication key (secret) as a private key and a key store in which a terminal key (secret) as a private key for a terminal held by the terminal and a terminal key (public) as a pair of public keys are registered. It is a new registration method for the terminal of the authentication key sharing system that has
If the third party is to present the personal identification information to guarantee, its own terminal key to the registered terminal is held (secret) and the registered terminal-to-terminal key (the public) was registered in the key store exists , The registered terminal
The terminal key (secret) held in the newly registered new terminal and the paired terminal key (public) are signed with the terminal key (secret) held by the registered terminal, and the signature generated by this signature. Execute the step of sending the completed terminal key (public) to the key store,
The keystore is
When the signature of the signed terminal key (public) is verified with the terminal key (public) of the registered terminal held in the key store, the terminal key (public) of the new terminal is used in the key store. run the step of registering to,
The registered terminal is
Execute the step of transmitting the usage conditions that restrict the use of the service to the new terminal, and execute the step.
The new terminal is
When registering the terminal key (public) in the keystore, the step of transmitting the terms of use to the keystore is executed.
The keystore is
A terminal new registration method, characterized in that a step of restricting the use of the service of the new terminal is executed according to the usage conditions .

Images