JP6581611B2 - Authentication key sharing system and authentication key sharing method - Google Patents

Description

  The present invention relates to an authentication key sharing system and an authentication key sharing method.

Internet users use various web services such as online banking and online shopping using a plurality of terminals such as personal computers, smartphones, and tablet terminals. When using a Web service, user authentication is required, and a user ID (IDentifier) and password are generally used.
However, there are many cases in which a password is stolen because an easily set password is guessed or a password is leaked from a Web service server due to unauthorized access.

As a user authentication technique that replaces the password authentication, there is a web service user authentication technique using public key cryptography, a de facto standard technique (FIDO: Fast IDentity Online) for passwordless authentication. In FIDO, a different public / private key pair is generated for each service, the public key is arranged on the service site side, and the secret key is confined in a secure area in the terminal. The use of a private key (signature for challenge / response authentication, etc.) is based on the premise that biometric authentication is performed on the terminal, and the use of the private key is performed within the secure area. Security is high because there is nothing to follow.
In FIDO, as a pre-stage of user authentication, a terminal owned by the user generates a private key / public key pair for public key encryption, stores the private key in the terminal, and registers the public key in the Web service server To do. When registering the public key, the Web service server confirms the identity of the user.
When the Web service server authenticates the user, (1) the Web service server generates a random number and sends it to the terminal, (2) the terminal signs the random number using the secret key and sends it to the Web service server, (3) The Web service server verifies the signature. If the signature verification in (3) is successful, the user authentication is successful, and the user can use the Web service.

  In FIDO, the secret key is required to be stored in the secure area of the terminal so that the secret key is not illegally taken out or used. By storing the private key in the secure area, it is possible to prevent the private key from being stolen, used by anyone other than the authorized private key owner, or accessed from an unauthorized program such as malware. However, if the secret key cannot be extracted from the secure area, there is a problem that a legitimate user cannot access the Web service server from another terminal. That is, the Web service cannot be used from a plurality of terminals.

FIG. 8 is a diagram for explaining a problem that occurs when a plurality of terminals corresponding to FIDO are used.
As shown in FIG. 8, the user accesses the service A server 98 and the service B server 99 using the terminal X91. Public key A 981 has been registered in service A server 98 and public key B 991 has been registered in service B server 99. A secret key A912 paired with the public key A981 and a secret key B913 paired with the public key B991 are stored in the secure area 911 of the terminal X91.
However, when using a new terminal, since there is no key in the secure area 921, it is necessary to generate and register a key pair again for each service. When using a plurality of terminals, only the number of terminals × the number of services Registration work is required, and convenience is low.

  For example, in order for the user to access the service A server 98 from the new terminal Y92, it is necessary to store the secret key A912 in the secure area 921 of the terminal Y92. However, since the private key A912 cannot be extracted from the secure area 911 of the terminal X91 (cannot be copied to the secure area 921 of the terminal Y92), user authentication cannot be performed at the terminal Y92. The same applies to the service B server 99. In order for the user to access the service A server 98 and the service B server 99 from the terminal Y92, it is necessary to re-register public keys from the terminal Y92 to the service A server 98 and the service B server 99. Re-registration is required only for the number of services (the number of servers) x the number of terminals, and it takes a lot of work including identity verification.

As a technique for solving the problem of re-registration when introducing a new terminal (using a plurality of terminals), there is a technique described in Non-Patent Document 1 that performs secure key sharing between terminals.
Non-Patent Document 1 discloses that an owner certificate (non-patented) with the same owner is assumed on the assumption that a third party confirms the identity of the terminal and issues an owner certificate to the terminal. There is shown a technique that enables a private key to be copied (duplicated) only between terminals that have issued user certificates described in Document 1.

FIG. 9 is a diagram for explaining private key copy between secure areas using an owner certificate.
As shown in FIG. 9, the terminal XX93 includes a secure area 931 corresponding to the owner certificate, and the terminal YY94 includes a secure area 941 corresponding to the owner certificate. The terminal management server 100 issues the owner certificate X934 after confirming the identity of the owner of the terminal XX93. The issued owner certificate X934 is stored in the secure area 931 of the terminal XX93. The same applies to the terminal YY94, and the owner certificate Y944 issued from the terminal management server 100 is stored in the secure area 941.

  When the owner indicated by the owner certificate X934 matches the owner indicated by the owner certificate Y944, the secret key A912 and the secret key B913 are copied from the secure area 931 of the terminal XX93 to the secure area 941 of the terminal YY94. It becomes possible. The user can authenticate the service A server 98 and the service B server 99 from the terminal YY 94 using the copied secret key A 942 and secret key B 943. Re-registration of the public key becomes unnecessary by copying the private key using the owner certificate.

FIG. 10 is a diagram for explaining functions required for a terminal in the standard technology (FIDO).
As shown in FIG. 10, the terminal 95 includes a Web application 951, an FIDO client 952, and a secure area 953 corresponding to the FIDO Authenticator (see the broken line in FIG. 10).
The secure area 953 includes a secret key generation unit 954, a secret key utilization unit 955, a secret key storage unit 956, and a biometric authentication unit 959. The secret key storage unit 956 stores a secret key A957 paired with the public key A and a secret key B958 paired with the public key B.

The FIDO client 952 issues a secret key generation request to the secret key generation unit 954 in accordance with the secret key generation request of the Web application 951. The secret key generation unit 954 receives an instruction from the normal area FIDO client 952 and generates a secret key.
Also, the FIDO client 952 issues a signature request to the secret key utilization unit 955 in accordance with the signature request at the time of authentication of the Web application 951. The private key using unit 955 receives an instruction from the FIDO client 952 in the normal area and uses the private key (signature, encryption, decryption, etc.).
The secret key storage unit 956 stores the secret key A957 and the secret key B958 generated by the secret key generation unit 954 or used by the secret key utilization unit 955.
The biometric authentication unit 959 receives an instruction from the FIDO client 952 in the normal area, and executes user authentication such as biometric (fingerprint, iris) authentication.

FIG. 11 is a diagram for explaining functions required for a terminal in a conventional authentication key sharing method (key copy).
As illustrated in FIG. 11, the terminal 96 includes a web application 961, an FIDO client 962, and a secure area 963. The secure area 963 includes a secret key generation unit 964, a secret key use unit 965, a secret key storage unit 966, a biometric authentication unit 969 corresponding to a FIDO Authenticator (see the broken line in FIG. 11), and a copy (duplication) As an additional function (refer to the one-dot chain line in FIG. 11), a secret key copy transmission unit 970 and a certificate management unit 971 (issue, storage, comparison, etc.) are provided. The secret key storage unit 966 stores a secret key A967 and a secret key B968.

In the secure area 963, the private key copy transmission unit 970 transmits the private key A967 and the private key B968 stored in the private key storage unit 966 to the certificate management unit 971 according to the request from the certificate management unit 971. The certificate management unit 971 issues, stores, and compares certificates using the private key A967 and the private key B968.
On the other hand, the secret key copy transmission unit 970 receives a secret key copy request from the other terminal 97 and transmits the secret key to the other terminal 97.
The additional function for copying is expensive because the scale of the necessary additional function is large and high quality is required for ensuring security.

Yusuke Ogata, Yoshihiko Omori, Takao Yamashita, Tetsuya Iwata, "Study on maintenance of secret key for authentication method using asymmetric key", IEICE Communication Society Conference, B-7-9, 2016.

In order to realize a conventional authentication key sharing method (key copy), it is necessary to additionally mount a function for copying a secret key in the terminal 96 as shown by a one-dot chain line in FIG. However, for the following reasons, it is assumed that it is costly to additionally implement a function for copying, and there is a concern that it will become an alienation of the spread.
Since the FIDO standard implementation does not assume the extraction of the secret key outside the terminal, this function is a function that should be implemented completely newly. A function that handles highly confidential authentication information is required to be executed in a secure area (TEE: Trusted Execution Environment) of the terminal. However, TEE provides only a limited development environment compared to a normal execution environment (Android or the like), and the cost of developing a large-scale function as a TEE application is high. In addition, since it has an interface for transmitting the secret key to the outside, a design that sufficiently considers security (encryption processing at the time of transmission, authentication processing of the copy destination terminal, etc.) is required. In addition, there is a demand for being robust so as not to be abused, and high software quality is required.

  The present invention has been made in view of such a background, and the present invention provides an authentication key sharing system and an authentication key sharing method for realizing sharing of an authentication secret key without copying the secret key between terminals. The issue is to provide.

In order to solve the above-described problem, the invention according to claim 1 includes a plurality of terminals that authenticate using a secret key, and a third-party server that performs identity verification of the owner of the terminal, and the terminal and the and the third party server, connected via a communication network, a authentication key sharing system for sharing the secret key for authentication between a plurality of said terminals, said terminal is connected to the communication network A secure area, which is an area managed to prevent unauthorized entry from the outside, with a client that obtains a Web service-specific AppID and a UserID that uniquely identifies a registered user from a Web server Within a secure area, a master code management unit that accepts input of a master code from the owner, and a run generated and stored by the third party server Subcode consisting beam string, the subcode management unit that acquires by dispensing from a third party server, using a combination of the sub-code and the AppID and the UserID and the master code, commonly owned It generates an input character string to be the same on the terminal, and a secret key generator for generating said secret key based on the input character string, the secret key generating unit of the terminal, the input string The third-party server stores the sub-code for generating the sub-code, and the third-party server stores the sub-code in response to the sub-code issuance request from the sub-code management unit of the other terminal. An authentication key sharing system is characterized in that the subcode is paid out.

The invention according to claim 2 comprises a plurality of terminals that authenticate using a secret key, and a third party server that verifies the identity of the owner of the terminal, the terminal and the third party server DOO is connected via a communication network, a authentication key sharing method of the authentication key sharing system for sharing the secret key for authentication between a plurality of the terminal, the terminal connected to the communication network AppID and specific Web service from the Web server acquires the uniquely identifying UserID users registered, has a secure area is an area that is managed so as not to unauthorized intrusion from the outside, the secure area And receiving a master code input from the owner, and a subcode comprising a random character string generated and stored by the third party server. Wherein the sub-code management step of obtaining by dispensing from a third party server, using a combination of the AppID and the UserID the master code and the subcode, the input character string to be same on the same owner terminal generate, execute and generating the secret key on the basis of the input character string, a step of storing said sub-code to generate the input string to the third party server, wherein the An authentication key sharing method , wherein a third party server executes a step of paying out the stored subcode in response to a request for issuing the subcode in the subcode management step of the other terminal ; did.

  In this way, the authentication key sharing system does not copy the secret key between the terminals, but can generate the same secret key on the terminals of the same owner. As a result, the key can be shared without direct exchange between the terminals, and the secret key can be shared among a plurality of terminals. In addition, the key registration operation for each service needs to be performed only once regardless of the number of terminals.

In addition, by storing in a distributed manner, it is possible to make it difficult for the entire input character string to be stolen by a single attack, and it is possible to increase resistance to the attack.

In addition, since the identification of the third party server is essential for the subcode delivery, unintentional illegal key sharing can be prevented. Even if the third party server is attacked and the subcode is leaked, the key cannot be generated unless both the master code and the master code are available.

  According to the present invention, it is possible to provide an authentication key sharing system and an authentication key sharing method for realizing sharing of an authentication secret key without copying the secret key between terminals.

It is a block diagram which shows the authentication key sharing system which concerns on embodiment of this invention. It is a figure which shows an example of the subcode management table of the terminal which comprises the authentication key sharing system which concerns on this embodiment. It is a figure which shows the operation | movement outline | summary of the authentication key sharing method of the authentication key sharing system which concerns on this embodiment. It is a sequence diagram which shows the flow of the pre-processing (master / subcode setting) which the authentication key sharing system which concerns on this embodiment performs. It is a sequence diagram which shows the key registration process which the authentication key sharing system which concerns on this embodiment performs. It is a figure explaining the asymmetric key generation process from the input character string performed by the secret key generation part of the terminal which comprises the authentication key sharing system which concerns on this embodiment. It is a sequence diagram which shows the regeneration process of the key which the authentication key sharing system which concerns on this embodiment performs. It is a figure explaining the problem which arises when using multiple terminals corresponding to FIDO. It is a figure explaining the private key copy between secure areas using an owner certificate (user certificate of nonpatent literature 1). It is a figure explaining the function calculated | required by the terminal in a standard technique (FIDO). It is a figure explaining the function calculated | required by the terminal in the conventional authentication key sharing method (key copy).

Hereinafter, an authentication key sharing system and the like in a mode for carrying out the present invention (hereinafter referred to as “the present embodiment”) will be described with reference to the drawings.
(Embodiment)
FIG. 1 is a configuration diagram showing an authentication key sharing system according to an embodiment of the present invention.
[Entire configuration of authentication key sharing system]
As shown in FIG. 1, an authentication key sharing system 1 according to the present embodiment includes terminals 10 (10A: a terminal that generates, registers, and uses a key) and terminals 10 (10B: a terminal that regenerates and uses a key). In addition, the network includes a third party server 20 and one or more Web services (devices) 30 used by the terminal 10. When it is not necessary to distinguish between the terminal 10 </ b> A and the terminal 10 </ b> B, the terminal 10 </ b> A is referred to as the terminal 10.
Note that the terminal 10, the third party server 20, the Web server 311 (described later) and the FIDO server 312 (described later) of the Web service 30 are connected via a communication network (not shown) and can communicate with each other. is there.
In the authentication key sharing system 1, a plurality of terminals 10 that authenticate using a secret key and a third party server 20 that performs identity verification of the owner of the terminal 10 are connected via a communication network. Share the authentication private key with.
The authentication key sharing system 1 does not copy the secret key between the terminals 10 but can generate the same secret key on the terminals 10 of the same owner so that the secret for authentication between the terminals 10 can be generated. Realize key sharing.

<Device configuration>
The terminal 10 includes a normal area 11 that is an area in which normal applications and the like operate, a secure area 12 that is an area that is managed so that malware and the like are not mixed (an area that is managed to prevent unauthorized entry from the outside), Is logically provided.
The normal area 11 is an environment in which a general application program is executed. The normal area 11 includes a Web client 111 and an FIDO client 112.

The Web client 111 issues a key registration request and an authentication request to the Web server 311 of the Web service 30 using the Web service.
The FIDO client 112 receives a key request from the FIDO server 312 of the Web service 30 and issues a key generation request to the secret key generation function unit 122 (described later). Also, the FIDO client 112 receives an authentication request from the FIDO server 312 of the Web service 30 and issues an authentication request to the secret key utilization unit 121 (described later).

  The secure area 12 is an area managed so that it cannot be illegally entered from the outside. The secure area 12 is an execution environment isolated from general application programs, and data and calculation processing are protected. The program is executed in a privileged mode of a CPU (Central Processing Unit) or an OS (Operating System), and a program in the secure area 12 and access to data can be accessed only by a specific program or a specific procedure.

  The secure area 12 includes a secret key utilization unit 121, a secret key generation function unit 122, a secret key storage unit 126, and a biometric authentication unit 127. The secret key generation function unit 122 includes a secret key generation logic 123 (secret key generation unit), a master code management unit 124, and a subcode management unit 125.

  The private key using unit 121 receives instructions from the FIDO client 112 in the normal area 11 and uses the private key (signature, encryption, decryption, etc.).

Secret key generation function unit 122 receives an instruction from the FIDO client 112 of the normal region 11, to generate the secret key to preparative also a specific input character string. In other words, the secret key generation function unit 122 generates a secret key by deriving a secret key that has been randomly generated from a specific input character string. By making it possible to generate the same secret key from the same input character string, the terminals 10 sharing the input character string can generate the same secret key.

The input character string uses a combination of a “master code” stored by the user (owner) and a “subcode” generated and stored by the third party server 20. The subcode is a random character string, and increases resistance to cracking attacks such as brute force attacks and dictionary attacks by increasing the entropy of the input character string. Acquisition of the subcode requires confirmation of the identity of the terminal owner by the third party server 20, and ensures that the payment is only made on the terminal owned by the same person.
The secret key generation function unit 122 is implemented as an extended function of a key generation unit required for standard technologies including FIDO.

The secret key generation logic 123 generates an input character string that is the same on the terminal 10 of the same owner using a combination of the master code and the subcode, and generates a secret key by deriving from the input character string. .
The secret key generation logic 123 generates an asymmetric key from the input character string (see FIG. 6 described later). Specifically, the secret key generation logic 123 uses a master code, a subcode, AppID (site ID), UserID, (user ID) as inputs in a standard technology including FIDO based on asymmetric key cryptography. A secret key unique to each user is derived and generated.

  The master code management unit 124 acquires a master code stored by the user (owner). The master code management unit 124 receives an input of a master code (for example, a character string) from the user. This master code is stored by the user himself. However, as long as only the user can refer to this master code, there is no particular limitation on management by a method other than storage. For example, as with conventional password management, use a management tool, print, lock, and store.

  The subcode management unit 125 obtains a subcode including a random character string generated and stored by the third party server 20 by paying out from the third party server 20. The subcode management unit 125 manages a subcode (random character string) (see FIG. 2 described later) issued from the subcode management function unit 212 (described later) of the third party server 20.

  The secret key storage unit 126 stores a secret key A paired with the public key A and a secret key B paired with the public key B. The secret key storage unit 126 is a storage (storage means) that can be accessed only from within the secure area 12.

  The biometric authentication unit 127 receives an instruction from the FIDO client 112 in the normal area 11 and executes user authentication such as information using biometric information (fingerprint, iris) or PIN (Personal Identification Number). The biometric authentication unit 127 performs biometric authentication of biometric information read by a scanner (not shown), for example.

<Third party server>
The third party server 20 stores the subcode for generating the input character string on the terminal 10 side in a distributed manner from the terminal 10 or the owner. The third party server 20 pays out the subcode in response to the subcode issue request from the subcode management unit 125 of the other terminal 10.
The third party server 20 includes an identity verification unit 211 and a subcode management function unit 212.
The identity verification unit 211 confirms the validity of the identity verification information by face-to-face presentation of a public ID (license or the like), presentation of an already issued electronic certificate, or the like.
In the case of the first terminal 10A, the subcode management function unit 212 generates a random character string as a subcode, associates the generated subcode with the user name, and stores it in the subcode management table 220 (see FIG. 2). To do. In the case of the second terminal 10B, the subcode management function unit 212 refers to the subcode management table 220 and acquires the subcode associated with the user name.

FIG. 2 is a diagram illustrating an example of the subcode management table 220 provided in the subcode management function unit 212 of the third party server 20.
As shown in FIG. 2, the subcode management table 220 includes columns of user names (user_x, User_y,...) And subcodes (9d3ed234ssg, 9filsk03os80,...) Linked to the user names. The user name is a name of a user who performs registration / authentication in the terminal 10, and the user is generally the terminal owner.
The subcode is a random character string (9d3ed234ssg, 9filsk03os80,...) Associated with the user name, and is generated and stored by the third party server 20. The subcode makes it difficult to guess the input character string as a random generation. Increases the entropy of the input string to make it resistant to cracking attacks such as brute force attacks and dictionary attacks. Acquisition of the subcode requires confirmation of the identity of the terminal owner by the third party server 20, and ensures that the payment is only made on the terminal owned by the same person.
Here, the input character string is divided and stored in a master code and a subcode (the master code is stored by the user and the subcode is stored in the third party server 20). By storing the input character string in the master code and the subcode in a distributed manner, it is possible to make it difficult for the entire input character string to be stolen by a single attack, and it is possible to increase resistance to the attack.

<Web service>
As shown in FIG. 1, the Web service (apparatus) 30 includes a Web server 311 and an FIDO server 312.
The web service (apparatus) 30 includes an authentication policy (not shown). This authentication policy includes information required for the terminal accessing the Web service, such as whether or not the authentication secret key can be shared, the authentication method and the authentication accuracy, and the storage location of the secret key.

When sharing the secret key between the terminals 10, the Web server 311 accepts a key registration request or authentication request for using the Web service from the Web client 111 of the terminal 10. For example, when the terminal 10 A that generates, registers, and uses a key issues a key registration request to the Web server 311, the Web server 311 refers to the authentication policy, and if the Web service is available, the FIDO server 312. Authentication request is output to. The FIDO server 312 transmits an ID (AppID) unique to the Web service, an ID (UserID) uniquely identifying the registered user, and a random challenge character string to the FIDO client 112 of the terminal 10A.
When the terminal 10B that regenerates and uses the key issues a key reproduction processing request to the Web server 311, the Web server 311 refers to the authentication policy, and if the Web service can be used, the FIDO server 312. Authentication request is output to. The FIDO server 312 transmits AppID, UserID, and a random challenge character string to the FIDO client 112 of the terminal 10B.

Hereinafter, an authentication key sharing method of the authentication key sharing system configured as described above will be described.
[Principle explanation]
First, the basic concept of the present invention will be described.
The authentication key sharing system 1 does not copy the secret key between the terminals 10 but can generate the same secret key on the terminals 10 of the same owner so that the secret for authentication between the terminals 10 can be generated. Realize key sharing.

FIG. 3 is a diagram showing an outline of the operation of the authentication key sharing method of the authentication key sharing system 1. FIG. 3 shows a terminal 10 (10A: a terminal that generates, registers, and uses a key; the first terminal) and a terminal 10 (10B: a key) among the devices that constitute the authentication key sharing system 1 according to the present embodiment. FIG. 3 is a diagram showing an extracted terminal and a third party server 20 that are regenerated and used.
As shown by reference symbol a in FIG. 3, the secret key generation function unit 122 receives a key generation request (during registration) from the FIDO client 112 in the normal area 11. The secret key generation function unit 122 has a partly expanded secret key generation function, and generates a secret key based on a specific input character string instead of generating a secret key that was conventionally randomly generated. . That is, the function addition has a feature (point 1) that is only a part of the secret key generation function. In addition, there is a feature (point 2) that a secret key can be shared without direct exchange between terminals. By allowing the same secret key to be generated, the terminals 10 sharing the input character string can generate the same secret key.

The input character string uses a combination of a “master code” stored by the user and a “subcode” generated and stored by the third party server 20. In other words, the input character string is divided into master codes and subcodes and distributedly stored, thereby having a feature (point 3) of high resistance to attacks.
The master code and the sub code are set by pre-processing (see FIG. 4 described later). That is, as shown by the symbol b in FIG. 3, the master code (input character string) is stored by the user X itself. The user X inputs / sets this master code in the terminal 10 (see symbol c in FIG. 3).

  On the other hand, as indicated by the symbol d in FIG. 3, the third party server 20 generates and stores the subcode in advance. The subcode is a random character string, and increases resistance to cracking attacks such as brute force attacks and dictionary attacks by increasing the entropy of the input character string. Acquisition of the subcode requires confirmation of the identity of the terminal owner by the third party server 20, and ensures that the payment is only made on the terminal owned by the same person. Even if the third party server 20 is attacked and the subcode leaks, the key cannot be generated unless both the master code and the master code are available. In addition, the subcode has a feature (point 4) that makes it difficult to guess an input character string as random generation and increases resistance.

When there is a subcode issue request from the user X, the third party server 20 pays out to the secret key generation function unit 122 after confirming the owner's identity, as indicated by a symbol e in FIG. (See FIG. 4 below). In other words, it has the feature (point 5) that the identity verification of the third-party server 20 is essential for the subcode delivery, and that unintentional illegal secret key sharing is prevented.
As shown by the symbol f in FIG. 3, the secret key generation function unit 122 generates based on a specific input character string (an input character string in which a master code and a subcode are combined) (FIGS. 5 and 6 described later). reference). The generated secret key is stored in the secret key storage unit 126.

[Processing flow of authentication key sharing system]
Next, in the authentication key sharing system 1 according to the present embodiment, (1) pre-processing (master and subcode setting), (2) key registration processing (terminal 10A), (3) asymmetric key from input character string A generation process and (4) a key regeneration process (terminal 10B) will be described.

<Pre-processing (master and subcode setting)>
In the authentication key sharing system 1 according to the present embodiment, it is necessary to set a master code and a subcode in the terminal 10 as a pre-stage of key generation / registration / use related to authentication. The pre-processing is shown below.

FIG. 4 is a sequence diagram showing a flow of pre-processing (master / subcode setting) executed by the authentication key sharing system 1 according to the present embodiment.
The user inputs a master code to the master code management unit 124 of the secret key generation function unit 122 of the terminal 10 (step S1). An arbitrary character string is set on the first terminal 10A, and the same character string as that on the first terminal is set on the second and subsequent terminals. The master code management unit 124 stores the master code input by the user (step S2).

  The user performs a subcode issuing operation on the subcode management unit 125 of the secret key generation function unit 122 of the terminal 10 (step S3). The subcode management unit 125 makes a subcode issue request to the subcode management function unit 212 of the third party server 20 (step S4). The subcode management function unit 212 outputs a confirmation request for confirming whether or not the subcode issuance request is appropriate to the identity confirmation unit 211 (step S5). In response to this confirmation request, the principal confirmation unit 211 transmits a request for principal confirmation information to the user (step S6).

In response to the request for the personal identification information from the third party server 20, the user presents the personal identification information to the third party server 20 (step S7). The presentation of the identity verification information is a face-to-face presentation of a public ID (license etc.) or a presentation of an already issued electronic certificate.
The identity verification unit 211 of the third party server 20 receives the identity verification information from the user and confirms the validity of the identity verification information (step S8). When confirming the validity of the identity verification information, the identity verification unit 211 outputs a confirmation OK to the subcode management function unit 212 (step S9).

  In the case of the terminal 10 (10A: a terminal that generates / registers / uses a key; the first terminal), the subcode management function unit 212 generates a random character string as a subcode (step S10). Then, the subcode management function unit 212 associates the generated subcode with the user name and stores it in the subcode management table 220 (see FIG. 2) (step S11).

On the other hand, the subcode management function unit 212 refers to the subcode management table 220 (see FIG. 2) in the case of the terminal 10 (10B: a terminal that regenerates and uses a key; the second terminal), The linked subcode is acquired (step S12).
The subcode management function unit 212 issues a subcode to the subcode management unit 125 of the secret key generation function unit 122 of the terminal 10 (step S13). The subcode management unit 125 stores this subcode (step S14).

<Key registration process (terminal 10A)>
In FIDO, it is necessary to perform registration processing (Registration) for each Web service. The secret key registration process in this embodiment will be described below.
In the present invention, the main registration process needs to be executed only once for each service regardless of the number of terminals. The operation of the terminal 10 that has performed the key registration process is shown as a terminal 10A.

FIG. 5 is a sequence diagram showing a key registration process (terminal 10A) executed by the authentication key sharing system 1 according to the present embodiment.
The web client 111 of the terminal 10A logs in to the web server 311 of the web service 30 and transmits a key registration request (step S21).
The Web server 311 outputs a registration request to the FIDO server 312 (step S22). The FIDO server 312 transmits a key request to the FIDO client 112 of the terminal 10 (step S23). In this key request, an ID (AppID) unique to the Web service, an ID (UserID) that uniquely identifies the registered user, and a random challenge character string are assigned.
Note that the dashed-lined box in FIG. 5 indicates the standard operation of FIDO authentication.

The FIDO client 112 of the terminal 10 receives the key request from the FIDO server 312 of the Web service 30 and outputs a key generation request to the secret key generation logic 123 of the secret key generation function unit 122 (step S24).
The secret key generation logic 123 of the secret key generation function unit 122 outputs a user authentication request to the biometric authentication unit 127 of the terminal 10 (step S25). The biometric authentication unit 127 receives a user authentication request from the secret key generation logic 123 of the secret key generation function unit 122, and performs biometric authentication of the user (step S26). The biometric authentication of the user is, for example, fingerprint authentication, iris authentication, or PIN. After the user's biometric authentication, the biometric authentication unit 127 transmits the authentication result to the secret key generation logic 123 (step S27).

The master code management unit 124 of the secret key generation function unit 122 acquires the master code and outputs the master code to the secret key generation logic 123 (step S28).
The subcode management unit 125 of the secret key generation function unit 122 acquires the subcode and outputs the subcode to the secret key generation logic 123 (step S29).

  As described above, when the Web client 111 of the terminal 10A transmits a key registration request to the Web server 311 of the Web service 30 (step S21), the biometric authentication unit 127 transmits the biometric authentication result of the user via the Web service 30. Is transmitted to the secret key generation logic 123 (step S27). Then, the master code management unit 124 acquires the master code and outputs it to the secret key generation logic 123 (step S28), and the subcode management unit 125 acquires the subcode and outputs it to the secret key generation logic 123 ( Step S29). Therefore, the authentication key sharing system 1 collects the user's biometric authentication result, master code, and subcode in the secret key generation logic 123 in response to a key registration request by the Web client 111 of the terminal 10A.

The secret key generation logic 123 of the secret key generation function unit 122 generates an asymmetric key pair from the acquired AppID, UserID, master code, and subcode (step S30). The generation of the asymmetric key pair will be described later with reference to FIG.
The secret key generation logic 123 stores the generated secret key in the secret key storage unit 126 (step S31).
The secret key generation logic 123 transmits a key generation response to the FIDO client 112 (step S32). Specifically, the secret key generation logic 123 sends the generated public key and the challenge character string signed with the secret key (response) to the FIDO client 112. Hereinafter, the FIDO client 112, the Web client 111, the Web server 311 and the FIDO server 312 of the Web service 30 complete the key registration by the standard operation.

That is, the FIDO client 112 transmits a key response to the FIDO server 312 of the Web service 30 (step S33).
The FIDO server 312 verifies the response of the received key (step S34). Then, the FIDO server 312 stores the public key in association with the UserID (step S35). Thereafter, the FIDO server 312 outputs a registration response to the Web server 311 (step S36). The web server 311 notifies the registration completion to the web client 111 of the terminal 10A (step S37).

<Asymmetric key generation process from input string>
FIG. 6 is a diagram for explaining an asymmetric key generation process from an input character string, which is executed by the secret key generation function unit 122 of the terminal 10.

(Input process)
The master code management unit 124 of the terminal 10 receives the input of the master code from the user and inputs the acquired master code to the secret key generation logic 123.
The subcode management unit 125 of the terminal 10 inputs the acquired subcode to the secret key generation logic 123. The subcode is generated and stored by the third party server 20.
The FIDO server 312 of the Web service 30 inputs an ID (AppID) unique to the Web service 30 and an ID (UserID) that uniquely identifies the registered user to the secret key generation logic 123. As described above, AppID and UserID are added as an input character string for generating a secret key in order to generate a secret key unique to the service and the user.

(Processing process)
The secret key generation logic 123 receives 1. master code, 2. subcode, 3. AppID, and 4. UserID.
The secret key generation logic 123 receives an input character string (1. master code, 2. subcode, 3. AppID, 4. UserID) and outputs an asymmetric key pair that is uniquely determined. For example, by executing the following processing process, the same asymmetric key pair can be generated if the input is the same.

  In step S101, all input character strings (1. master code, 2. subcode, 3. AppID, 4. UserID) are combined into a single character string (“character string combination”). The joining order is arbitrary, but always (1. Master code, 2. Sub code, 3. AppID, 4. UserID) are joined in the same order.

  In step S102, a key is generated ("Key Derivation"). A key having a sufficiently long specific length (for example, 128 bits) is generated from this input character string. A technique such as PBKDF2 (RFC2898) is used for key generation.

  In step S103, the generated key is input as a seed into a pseudo-random number generator (not shown) to generate a random number sequence ("pseudo-random number generation").

In step S104, the generated number sequence is given to an asymmetric key generation algorithm (eg, DSA, RSA, etc.) to generate an asymmetric key (“Generate Asymmetric Key”).
The asymmetric key generated by this processing process is not a secret key that is randomly generated as in the conventional example, but a public key that is paired with a secret key that is generated based on a specific input character string. By allowing the same secret key to be generated from the same input character string, terminals sharing the input character string can generate the same secret key.

(Output process)
The secret key generation logic 123 outputs the generated secret key and public key. The private key storage unit 126 of the terminal 10 stores the generated private key after verifying the response. In addition, the public key that is the secret key pair is stored in the FIDO server 312 of the Web service 30 in association with the UserID.

<Key regeneration process (terminal 10B)>
In the present embodiment, by setting the same master code and subcode in advance, even the terminal 10B other than the terminal 10A that has generated and registered the key can regenerate the same secret key. By regenerating the same secret key, FIDO authentication can be used without re-registration.
Assuming the case where key generation / registration is performed in the terminal 10A, a processing procedure for executing authentication in the terminal 10B in which the same master code and subcode are set is shown.

FIG. 7 is a sequence diagram showing a key regeneration process (terminal 10B) executed by the authentication key sharing system 1 according to the present embodiment.
The Web client 111 of the terminal 10B transmits an authentication request to the Web server 311 of the Web service 30 (Step S41).
The Web server 311 outputs an authentication request to the FIDO server 312 (step S42). The FIDO server 312 transmits an authentication request to the FIDO client 112 of the terminal 10 (step S43). In this authentication request, an ID (AppID) unique to the Web service, an ID (UserID) uniquely identifying a registered user, and a random challenge character string are given.
In addition, the dashed-line frame box in FIG. 7 indicates the standard operation of FIDO authentication.

The FIDO client 112 of the terminal 10B receives the authentication request from the FIDO server 312 of the Web service 30, and outputs an authentication request to the secret key utilization unit 121 of the terminal 10B (Step S44).
The private key using unit 121 checks whether there is a key associated with the AppID (step S45). The secret key utilization unit 121 outputs a key generation request to the secret key generation logic 123 of the secret key generation function unit 122 (step S46).

  The secret key generation logic 123 outputs a user authentication request to the biometric authentication unit 127 of the terminal 10B (Step S47). The biometric authentication unit 127 receives a user authentication request from the secret key generation logic 123 of the secret key generation function unit 122, and performs biometric authentication of the user (step S48). The biometric authentication of the user is, for example, fingerprint authentication, iris authentication, or PIN. After the user's biometric authentication, the biometric authentication unit 127 transmits the authentication result to the secret key generation logic 123 (step S49).

The master code management unit 124 of the secret key generation function unit 122 acquires the master code and outputs the master code to the secret key generation logic 123 (step S50).
The subcode management unit 125 of the secret key generation function unit 122 acquires the subcode and outputs the subcode to the secret key generation logic 123 (step S51).

The secret key generation logic 123 of the secret key generation function unit 122 generates an asymmetric key pair from the acquired AppID, UserID, master code, and subcode (step S52). The generation of the asymmetric key pair has been described with reference to FIG.
The secret key generation logic 123 stores the generated secret key in the secret key storage unit 126 (Step S53).
The secret key generation logic 123 acquires the secret key from the secret key utilization unit 121 of the terminal 10B (step S54).

The secret key utilization unit 121 signs the challenge character string with the secret key (step S55). Then, the secret key utilization unit 121 outputs an authentication response to the FIDO client 112 (step S56).
The FIDO client 112 transmits an authentication response (response) to the FIDO server 312 of the Web service 30 (step S57).
The FIDO server 312 verifies the response of the received public key (step S58). Specifically, the FIDO server 312 is sent at the time of registration and verifies with the registered public key. The FIDO server 312 stores the public key in association with the UserID. Thereafter, the FIDO server 312 outputs an authentication response to the Web server 311 (step S59). The web server 311 notifies the registration completion to the web client 111 of the terminal 10B (step S60).

  As described above, the authentication key sharing system 1 according to this embodiment is a secure area 12 that is managed so that the terminal 10 cannot illegally enter from the outside, and is an area other than the secure area 12. And a master code management unit 124 that receives an input of a master code from the owner, and a subcode consisting of a random character string generated and stored by the third party server 20, Using the subcode management unit 125 that is acquired by paying out from the three-party server 20 and the combination of the master code and the subcode, the same input character string is generated on the terminal 10 of the same owner, and the input character And a secret key generation logic 123 that generates a secret key based on the sequence.

  In the authentication key sharing method of the authentication key sharing system 1, the terminal 10 acquires a master code stored by the owner in the secure area 12 and a random character string generated and stored by the third party server 20. Using the combination of the master code and the subcode, and generating the same input character string on the terminal 10 of the same owner, Generating a secret key based on the input character string.

The prior art has the following disadvantages.
The FIDO standard implementation does not assume that the secret key is taken out of the terminal. For this reason, when developing as an application in the secure area, the cost increases because the development environment is limited. In addition, since it has an interface for transmitting the secret key to the outside, a design that fully considers security is required. Also, robust and high software quality is necessary so that it cannot be misused.
In contrast, in this embodiment, the secret key is not copied between terminals, but the same secret key can be generated on terminals of the same owner. As a result, the key can be shared without direct exchange between the terminals, and the authentication secret key can be shared among a plurality of terminals. In addition, the authentication secret key can be shared only by partially extending the key generation function.

Hereinafter, specific effects of this embodiment will be described.
In the present embodiment, it is possible to generate the same authentication secret key between terminals of the same owner. For this reason, the key registration operation for each service needs to be performed only once regardless of the number of terminals. The function for this purpose is a function addition to a part of the key generation function required for the standard technology (FIDO), and thus is superior in terms of spread compared to the conventional technology (key copy) that needs to newly implement a copy function. .

  In the prior art (key copy), the user knows which terminal generated and registered the key for each service (that is, which terminal has the private key), and uses the service on other terminals In this case, it was necessary to explicitly copy the key from the terminal that generated the key to the new terminal.

  In this embodiment, the same master code and subcode are set in advance, so that the same secret key is regenerated by the terminal other than the terminal that has generated and registered the key, thereby using the FIDO authentication without re-registration. be able to. That is, if the same master code and subcode are set, the same secret key is automatically generated for each service at any terminal. For this reason, there is no need to be aware of which terminal has registered the key for each service, and the burden on the user is small.

  In this embodiment, the subcode is a random character string. Since the subcode is randomly generated, the input character string can be made difficult to guess, and the entropy of the input character string can be increased. It can be resistant to cracking attacks such as brute force attacks and dictionary attacks.

  In this embodiment, since the secret key generation logic 123 is implemented as an extended function of a key generation unit required for a standard technology including FIDO, a function addition to a part of the key generation function required for the standard technology (FIDO) For this reason, it is superior in terms of spreadability compared to the conventional technique (key copy) that needs to newly implement a copy function.

In this embodiment, when a secret key is shared among a plurality of terminals 10, the secret key generation logic 123 of each terminal 10 generates a secret key by deriving from the input character string without exchanging the secret key. The authentication secret key can be shared among a plurality of terminals without copying the secret key between the terminals.

  In the present embodiment, the terminal 10 divides the generated input character string into a master code and a subcode, and stores the subcode in the third party server 20. The entire input character string can be made difficult to be stolen, and the resistance to attacks can be increased.

  In the present embodiment, the third party server 20 pays out the subcode after confirming the owner's identity. The third party server pays out the subcode in response to the subcode issue request from the subcode management unit 125 of the other terminal 10. Since the identification of the third party server 20 is indispensable for the subcode delivery, unintentional illegal key sharing can be prevented. Even if the third party server 20 is attacked and the subcode leaks, the key cannot be generated unless both the master code and the master code are available.

In this embodiment, the secret key generation logic 123 is input to an input character string (master code, subcode, AppID, UserID) in a standard technology including FIDO based on asymmetric key cryptography. Deriving and generating a secret key for authentication.
This makes it possible to generate the same asymmetric key pair if the inputs are the same.

Of the processes described in the above embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the specification and drawings can be arbitrarily changed unless otherwise specified.
Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part of the distribution / integration may be functionally or physically distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured.

  Each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Further, each of the above-described configurations, functions, and the like may be realized by software for interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files for realizing each function is stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), an IC (Integrated Circuit) card, an SD (Secure Digital) card, an optical disk, etc. It can be held on a recording medium.

1 authentication key sharing system 10 terminal 10A terminal (terminal for generating / registering / using a key; first terminal)
10B terminal (terminal that regenerates and uses key; second terminal)
DESCRIPTION OF SYMBOLS 11 Normal area | region 12 Secure area | region 20 Third party server 30 Web service 111 Web client 112 FIDO client 121 Secret key utilization part 122 Secret key generation function part 123 Secret key generation logic (secret key generation part)
124 Master Code Management Unit 125 Subcode Management Unit 126 Secret Key Storage Unit 127 Biometric Authentication Unit 220 Subcode Management Table 211 Identity Confirmation Unit 212 Subcode Management Function Unit 311 Web Service Server 312 FIDO Server

Claims (2)

A plurality of terminals that authenticate using a secret key, and a third party server that performs identity verification of the owner of the terminal, the terminal and the third party server are connected via a communication network, a the authentication key sharing system for sharing a secret key for authentication between a plurality of said terminals,
The terminal
A client that acquires a Web service-specific AppID and a UserID that uniquely identifies a registered user from a Web server connected to the communication network;
It has a secure area that is managed to prevent unauthorized entry from the outside,
Within the secure area,
A master code management unit that accepts input of a master code from the owner;
A subcode management unit that acquires and obtains a subcode consisting of a random character string generated and stored by the third party server from the third party server;
Using a combination of the AppID and the sub-code and the UserID and the master code, is on the same owner of the terminal generates an input string of the same, generating the secret key on the basis of the input character string provided with a secret key generation unit for, the,
The secret key generation unit of the terminal is
Storing the subcode for generating the input character string in the third party server;
The third party server is
In response to a request for issuing the subcode from the subcode management unit of another terminal, the stored subcode is issued.
Authentication key sharing system, wherein a call. A plurality of terminals that authenticate using a secret key, and a third party server that performs identity verification of the owner of the terminal, the terminal and the third party server are connected via a communication network, an authentication key agreement method of the authentication key sharing system for sharing the secret key for authentication between a plurality of said terminals,
The terminal
Acquire a Web service-specific AppID and a UserID that uniquely identifies a registered user from a Web server connected to the communication network;
It has a secure area that is managed to prevent unauthorized entry from outside ,
Within the secure area,
Receiving an input of a master code from the owner;
A subcode management step of acquiring a subcode consisting of a random character string generated / stored by the third party server by paying out the third party server;
Using a combination of the AppID and the sub-code and the UserID and the master code, is on the same owner of the terminal generates an input string of the same, generating the secret key on the basis of the input character string And steps to
Causing the third-party server to store the subcode for generating the input character string ; and
The third party server is
In response to the subcode issuance request in the subcode management step of another terminal, a step of paying out the stored subcode is executed.
An authentication key sharing method characterized by the above .

Images