JP6438901B2 - Authentication system, key processing cooperation method, and key processing cooperation program - Google Patents

Description

  The present invention relates to a technology of encryption by an electronic key (hereinafter, may be simply referred to as "key").

  It is considered important how to improve the security when a terminal such as a smart phone uses the web service. In recent years, as a password-independent online authentication, online authentication using key encryption has been proposed by the Fast Identity Online (FIDO) Alliance and the like. In this on-line authentication, the web service has a public key, and the terminal has a secret key. The terminal includes an authentication module that can be used for online authentication, and can perform authentication while keeping a secret key in a dedicated area of the authentication module. Note that “confining” the key means that the key generated in the area is not taken out of the area until the key is deleted.

  Under various circumstances, if the authentication module included in the terminal is lost, the secret key in the authentication module is also lost. However, even if the terminal is equipped with a new authentication module, it is not possible to prepare the same secret key as the one before loss. As a result, the terminal which has lost the secret key can no longer use the web service in a mode that continues before loss of the secret key. At the moment, FIDO does not specify the key recovery technology.

  Patent Document 1 discloses a technique for setting a group capable of executing personal identification for a plurality of specific users and recovering the key if the personal identification can be performed.

JP 2000-286831 A

  However, even with the technology of Patent Document 1, it is difficult to set a group that can execute the identity verification for the web service used by an unspecified number of persons, so the identity verification is performed. However, key recovery can not be performed.

  In view of such circumstances, it is an object of the present invention to avoid the loss of a key used for online authentication for WEB service and to reliably execute online authentication for WEB service.

  In order to solve the above-described problems, the invention according to claim 1 enables communication between a terminal provided with an authentication module for performing user authentication, a web service used by the terminal, and a key store having a predetermined key. An authentication system connected to the web service, the web service includes a web service authentication public key used for authentication for the terminal to access the web service, and the key store includes the web A secret key for WEB service authentication, which is a pair for a service authentication public key, and an authentication module authentication private key used for authentication of the authentication module are enclosed in a tamper resistant area, and the terminal is the authentication module It has an authentication module authentication public key that is a pair of authentication private keys, the authentication module authentication public key and the authentication public key The information to be processed using the private key testimony module authentication, send and receive encrypted between the terminal and the key store, and wherein the.

  Further, according to the invention described in claim 5, an authentication in which a terminal including an authentication module for performing user authentication, a web service used by the terminal, and a key store having a predetermined key are communicably connected. A key processing cooperation method in a system, wherein the web service has a web service authentication public key used for authentication for the terminal to access the web service, and the key store is for the web service authentication. In the aspect of confining the secret key for WEB service authentication which is a public key pair in the tamper resistant area, the key store is used for the authentication of the authentication module, the authentication module authentication private key and the authentication module authentication public Generating a key and transmitting the authentication module authentication public key to the terminal; The information to be processed using the Yuru public key and the authentication module authentication private key for authentication, the step of transmitting and receiving encrypted between the terminal and the key store, run the city, characterized in that.

  The invention according to claim 6 is an authentication method in which a terminal including an authentication module for performing user authentication, a web service used by the terminal, and a key store having a predetermined key are communicably connected. The computer as the key store of the system, the web service has a public key for web service authentication used for authentication for the terminal to access the web service, and the key store is for the web service authentication. In the aspect of confining the secret key for WEB service authentication which is a public key pair in the tamper resistant area, the authentication module authentication private key and the authentication module authentication public key used for authentication of the authentication module are generated. Means for transmitting the authentication module authentication public key to the terminal; and for the authentication module authentication Hirakikagi and the authentication module information to be processed using the authentication private key, a key processing cooperative program for functioning as a means for transmitting and receiving encrypted between the terminal and the key store.

According to the invention described in claims 1, 5, and 6, the authentication module authentication public key on the terminal side and the authentication module authentication private key on the key store side use the user authentication result and the secret for WEB service authentication. By associating the key with the key, the processing order and relationship between the two can be made unique. Conventionally, when using a secret key, authentication is required, and when using two types of secret keys such as a secret key for authentication module authentication of a key store and a secret key for WEB service authentication, users are required for each use of the secret key Authentication (that is, user authentication is performed twice), and it is necessary to obtain approval in each authentication, but in this method, it is possible to make the key use order unique from the user authentication, The authentication of the user may be performed once. As a result, the amount of operation of the user at the time of authentication in the web service can be made the same as in the conventional FIDO authentication method. Therefore, it is possible to detect and prevent unauthorized operations such as impersonation and man-in-the-middle attacks that directly access the key store, and high security can be realized.
In addition, since the area where the key can be processed is limited, plaintext can only be handled within a limited area, and even an operator of the key store can falsify information, eavesdropping, and improperly transmit and receive information. It can not be used and contributes to the improvement of security.
Further, since the WEB service authentication private key does not exist on the terminal side, the user can not lose the WEB service authentication private key, and it is possible to avoid the interruption of the continuous use of the web service.
Therefore, it is possible to prevent the loss of the key used for the on-line authentication for the web service, and to reliably execute the on-line authentication for the web service.

  The invention according to claim 2 is the invention according to claim 1, wherein the authentication for accessing the key store is performed for user authentication due to release of the screen lock set to the terminal. It is characterized by making it the authentication which gives the authority to use the public key for module authentication.

  According to the second aspect of the invention, it is possible to introduce a mechanism that enables access to the key store only when the success of the user authentication by the screen lock release is realized. Therefore, access to the public key for authentication module authentication from an external application or the like can be restricted, unauthorized use of the key can be prevented, and security can be further improved.

  The invention according to claim 3 is the invention according to claim 2, wherein the WEB service registers the user of the terminal, or the user of the terminal attempting to access the WEB service. When performing authentication, the terminal has the public key for the authentication module authentication, and the key store has the secret key for the authentication module authentication, the terminal and the key When confirming with the store and holding of the key is not established, when the WEB service registers the user of the terminal, or when authenticating the user of the terminal attempting to access the WEB service Performing processing for establishing holding of the key between the terminal and the key store.

  According to the third aspect of the present invention, at the stage of registration of the user in the WEB service or at the stage of authentication of the user of the terminal attempting to access the WEB service, the key is exchanged between the terminal and the key store. By ensuring that the screen unlocking of the terminal doubles as user authentication on the key store side in order to realize cross-shareholding, after the cross-crossing of keys is established, only user authentication for WEB services can be completed, Processing load can be reduced.

  The invention according to claim 4 is the authentication system according to any one of claims 1 to 3, wherein the key store is disposed on the Internet side as a first key store, and a predetermined key Processing result when the second key store having the key is disposed on the local network side, the process related to the initial registration of the user of the terminal is executed by the second key store, and the process is executed by the second key store Are encrypted and sent to the first key store.

  According to the invention as set forth in claim 4, the second key store disposed on the local network side which strictly manages the information to be held performs initial registration of the user of the terminal. Etc. can be made more difficult, and security can be further improved.

  According to the present invention, it is possible to avoid the loss of a key used for online authentication for WEB service, and to execute online authentication for WEB service reliably.

It is a whole block diagram of the authentication system of this embodiment. It is a structural diagram of the information of the authentication module as information which a metadata service hold | maintains. It is a structural diagram of the information which a terminal holds, (a) is a structural diagram of authentication management information, (b) is a structural diagram of account management information. It is a structural diagram of the information of user management DB which an authentication key relay type | mold keystore hold | maintains. It is a sequence diagram of a scenario A advance setting. It is a sequence diagram of scenario B initial registration (1/3). It is a sequence diagram of scenario B initial registration (2/3). It is a sequence diagram of scenario B initial registration (3/3). It is a sequence diagram of registration (1/3) to a scenario C WEB site. It is a sequence diagram of registration (2/3) to a scenario C WEB site. It is a sequence diagram of registration (3/3) to scenario C WEB site. It is a sequence diagram of the authentication (1/3) in a scenario D WEB site. It is a sequence diagram of the authentication (2/3) in a scenario D WEB site. It is a sequence diagram of the authentication (3/3) in a scenario D WEB site. It is explanatory drawing of the modification (1/2) of authentication key relay type | mold key store, (a) is a block diagram of authentication key relay type | mold keystore arrange | positioned at the Internet side and the local network side, (b) FIG. 10 is a structural diagram of information of a user management DB generated at an authentication key relay type keystore on the local network side at the initial registration stage of a terminal. It is explanatory drawing of the modification (2/2) of authentication key relay type | mold key store, (a) is a block diagram of authentication key relay type | mold keystore arrange | positioned at the Internet side and the local network side, (b) FIG. 10 is a structural diagram of information of a user management DB held in an authentication key relay type key store on the local network side at the stage of registration / authentication of the web service. It is a figure explaining the authentication method of FIDOAlliance. It is a figure explaining the feature of the authentication method of FIDOAlliance. It is a figure explaining the utilization procedure of FIDOAlliance. It is a figure explaining the problem of the authentication (FIDO) using a public key, and (a) is a figure which shows the structure which a terminal equips with the authentication module which loses, (b) is a structure which a terminal equips (new) authentication module. FIG. It is a figure explaining directionality of solution of the problem of FIG. FIG. 21 is a diagram for explaining the problem in FIG. 21. (a) is a case where the WEB service authentication secret key is on the authentication module side of the terminal, and (b) is on the authentication key relay type keystore side.

Embodiments of the present invention will be described in detail with reference to the drawings.
(Background explanation)
In Web services, authentication by PW (Password) has reached its limit. The current situation is that unauthorized manipulation of accounts due to dictionary attacks etc. frequently occurs. Key authentication is being considered as an authentication method that does not depend on PW (standards development group; FIDO Alliance, launched in 2012).
The First Identity Entity Online (FIDO) Alliance enhances security by using it for authentication while keeping the private key in the place where it was generated. FIDO Alliance is based on standardized Public Key Infrastructure (PKI). There are two standard protocols, one is an authentication U2F (Universal Second Factor) protocol that has evolved two-factor authentication technology, and the other is not using a password via a device such as a mobile that supports FIDO standards. It is an authentication UAF (Universal Authentication Framework) protocol. FIDO standard authentication supports biometric authentication technology, TPM (Trusted Platform Module), NFC (Near Field Communication), and supports devices and plug-ins. Therefore, WEB sites and cloud applications are also FIDO compliant. The corresponding device can enhance online authentication.

<Authentication method of FIDO Alliance>
FIG. 17 is a diagram for explaining an authentication method of FIDO Alliance.
As shown in FIG. 17, the web service 10 has an account 11 and a web service authentication public key PK1 associated with the account 11. A terminal 20 such as a smart phone can be connected to the authentication module 30 of FIDO Alliance. The authentication module 30 includes an authentication determination module 31, and a key processing storage area R1 for storing the WEB service authentication private key SK1. The WEB service 10 and the terminal 20 to which the authentication module 30 is connected perform authentication conforming to the FIDO (UAF) protocol.
In the WEB service 10, the account 11 and the public key PK1 are associated.

  As shown in FIG. 17, a pair of secret key SK1 and public key PK1 is generated by the authentication device (the authentication module 30 in FIG. 17), and the secret key SK1 is confined in the authentication device. Containing means that the private key SK1 is not extracted from the key processing storage area R1 of the authentication module 30 from generation of the key to deletion thereof. The security is enhanced by using for authentication while keeping the secret key SK1 in the place where it is generated (key processing storage area R1). As a device for enhancing security, authentication with a key confined in an authentication device further strengthens security by combining the nature of authentication with possession.

<Features of FIDO Alliance's authentication method>
FIG. 18 is a diagram for explaining the features of the FIDO Alliance authentication method.
As shown in FIG. 18, the web service 10 has a web service application 13 and a FIDO server 15, and the web service application 13 refers to the account 11 stored in the user management DB 14. The FIDO server 15 has a key management area 16 for storing the public key PK1 for web service authentication.
The WEB service 10 mutually references the information 3 of the authentication module with the metadata service 1. The metadata service 1 has a public key PK2 for metadata service. The information 3 of the authentication module describes information such as the accuracy of authentication of an authentication method of the authentication module (PIN (Personal Identification Number), iris, fingerprint or the like).

  The terminal 20 has a browser / application 21, an FIDO client 22, authentication management information 23, and an authentication module driver 24 (an application may be abbreviated as an "application"). The FIDO client 22 performs authentication with the WEB service 10 in accordance with the authentication policy on the WEB service 10 side in compliance with the FIDO (UAF) protocol. The authentication policy refers to the condition of the authentication method required for the service and the strength of authentication, which the WEB service 10 side presents to the user.

  The authentication module 30 includes an authentication module driver 24, an authentication determination module 31, and a key processing storage area R1. In the case of FIG. 18, the key processing storage area R1 stores the secret key SK2 for metadata service in addition to the secret key SK1 for WEB service authentication. The authentication module 30 is allowed various forms. If FIDO's UAF protocol works, it does not matter whether it is implemented in hardware or software. Also, the terminal 20 may be equipped or removable.

The authentication determination module 31 uses the Credentials registered in advance in the authentication module by the user, and verifies the information presented from the user with the Credential information at the time of the user authentication, and determines the quality. Hereinafter, information for authenticating the user, such as a PIN code and biometric information, will be referred to as Credential. If the information presented by the user matches the Credential information, then permission to generate the secret key / public key (when registering to the WEB service 10) or permission to use the secret key (authentication to the WEB service 10) Give time).
The key processing storage area R1 has a function related to the key generation, signature, encryption, decryption, etc., and a function of storing the key itself necessary for the key processing.

Here, the type of key will be described.
There are two types of keys: Web services public key / secret key and metadata service public key / secret key.
The public key and secret key for web service generate different keys for each web service and each account.
In addition, a public key / private key for metadata service is issued for each model of the authentication module (specification in which an authentication method, a storage area of keys, etc. are defined). Generates a secret key and a public key at the timing when the certification is obtained as an authentication module of FIDO. The secret key is embedded in the authentication module and shipped.

The features of FIDO certification are as follows.
Since the authentication level of the user to be obtained is different for each WEB service 10, it is necessary to correspond to various authentication levels, and an authentication method (a method for identifying a user such as PIN, fingerprint or iris) can be set on the WEB service 10 side. It is supposed to be.
The user of the terminal 20 needs to use the authentication determination module 31 equipped with the authentication determination module, which satisfies the authentication policy specified on the WEB service 10 side. The WEB service 10 can verify which model of authentication module is used by using the metadata service 1.

<Procedure of using FIDO Alliance>
FIG. 19 is a diagram for explaining the use procedure of FIDO Alliance.
(Procedure 1) Pre-Registration As shown in FIG. 19, a PIN code and biometric information are registered in the authentication module 30.

(Procedure 2) Account Creation in WEB Service As shown in FIG. 19, information is entered in the account input form, and the identity of the user is confirmed on the WEB service 10 side. Set the ID (login name etc.) and password.

(Procedure 3) Switching of the Authentication Method to the FIDO System of the WEB Service As shown in FIG. 19, the WEB service 10 is logged in with the password, and the switching process is executed for the FIDO system authentication. When registering in the web service 10, the authentication module 30 authenticates the user. If there is no problem, a pair of public key PK1 and secret key SK1 is generated in the authentication module 30, and the public key PK1 is sent to the WEB service 10. The public key PK1 is signed and sent with a secret key SK2 for metadata service. The WEB service 10 refers to the metadata and verifies it with the public key PK2 in the metadata service 1.

(Procedure 4) Authentication by FIDO Method As shown in FIG. 19, since there is an authentication request from the WEB service 10 side, the authentication module 30 executes the authentication of the user. If there is no problem, access permission to the secret keys SK1 and SK2 of the key processing storage area R1 is given, the signature is made with the secret keys SK1 and SK2, and the signature is returned to the WEB service 10 side. On the WEB service 10 side, if the signature can be verified with the public key PK1 linked to the account 11, it is determined that the authentication is OK.

<Problems of Authentication Using Public Key (FIDO)>
FIG. 20 is a diagram for explaining the problem of authentication (FIDO) using a public key.
In the case of authentication using a public key (FIDO), there is a problem that since the key is confined in the authentication device, if the authentication device is lost, the private key is also lost.
Specifically, as shown in FIG. 20A, when the terminal 20 to which the authentication module 30 is attached authenticates FIDO and uses the WEB service 10, the authentication module 30 is lost due to various circumstances (see FIG. 20A). It is assumed that the secret key SK1 is also lost. At this time, even if a new authentication module is prepared as the (new) authentication module 30A and the (new) authentication module 30A is attached to the terminal 20, as shown in FIG. 20 (b), the public key held by the web service 10 The (new) authentication module 30A does not have (or can not create) a secret key as a pair of PK1. As a result, the user of the terminal 20 can not use the web service 10 in a mode that continues before the loss of the secret key SK1.
Although FIDO stipulates new key registration, it does not stipulate measures for dealing with lost keys in the standardization technology and does not address the above problems.

<Direction of solution to the problems in Fig. 20>
FIG. 21 is a diagram for explaining the direction of solving the problems in FIG.
As shown in FIG. 21, the secret key SK1 for WEB service authentication which is a pair of the public key PK1 for WEB service authentication of the WEB service 10 is a server on the Internet (hereinafter referred to as authentication key relay type key store 40) store. The relationship between the secret key SK1 and the authentication module 30 is held in the authentication key relay type key store 40. That is, a system is proposed in which the processing relating to the secret key, which has been executed in the authentication module according to the FIDO protocol up to now, is executed on the authentication key relay type keystore 40 side.

<Issue of FIG. 21>
FIG. 22 is a diagram for explaining the problem of FIG.
As shown in FIG. 22A, the authentication determination module 31 and the key processing storage area R1 for storing the secret key SK1 are closed in the authentication module 30. Therefore, when the WEB service authentication secret key SK1 is on the authentication module 30 side of the terminal 20, it is guaranteed that the authentication result of the user by the authentication judgment module 31 is associated with the processing of the secret key SK1. .

  However, as shown in FIG. 22B, when the WEB service authentication secret key SK1 is on the authentication key relay type key store 40 side, the secret key SK1 is not in the key processing storage area R1. It is not guaranteed that the authentication result of the user is associated with the processing of the secret key SK1. Therefore, even if the web service 10 receives the signature with the secret key SK1, the web service 10 authenticates without the intervention of the authentication determination module 31 whether the signature is a result due to the authentication determination module 31 correctly authenticating. The key relay type key store 40 is accessed, and it can not be determined whether it is a product resulting from the processing of the secret key SK1. As a result, the WEB service authentication secret key SK1 in the authentication key relay type key store 40 may be illegally used to perform spoofing.

[Authentication system configuration]
FIG. 1 is an overall configuration diagram showing an authentication system of the present embodiment. As shown in FIG. 1, the authentication system 100 according to the present embodiment includes a WEB service 10, a terminal 20, an authentication module 30 (authentication device), an authentication key relay type key store 40 (key store), and a metadata service. 1 and the certificate authority 50.

<WEB service>
The web service 10 has a web site online, and the terminal 20 uses it to provide a predetermined service (web service) to the user of the terminal 20. The web service 10 has a web service application 13 and a FIDO server 15.

  The web service application 13 is an application that executes a process for providing a web service. The web service application 13 has a user management DB 14 that stores an account 11 created for each user.

The FIDO server 15 is a server that performs authentication by FIDO. The FIDO server 15 has a key management area 16 for storing the public key PK1 for web service authentication.
The web service authentication public key PK1 is a public key used when authenticating the user of the terminal 20 using the web service.
Also, the FIDO server 15 can refer to the information 3 of the authentication module of the metadata service 1.

<Terminal>
The terminal 120 is a mobile terminal such as a smartphone, a mobile phone, or a tablet, a notebook / desktop PC, and various electronic devices. In the present embodiment, a smart phone is taken as an example. The terminal 20 includes a browser application 21, an FIDO client 22, authentication management information 23, an authentication module driver 24, a terminal side cooperation authentication function 25, a screen unlocking function 26, and an OS account management function 27. And OS key processing storage area R2. The terminal 120 includes an authentication module 30 that performs user authentication.

The browser application 21 browses the web site of the web service 10.
The FIDO client 22 requests the FIDO server 15 for processing required for authentication by FIDO.
The authentication management information 23 is information that associates and manages various values for authenticating the user. Details of the authentication management information 23 will be described later.
The authentication module driver 24 is a driver for the terminal 20 to control the process of the authentication module 30.

The terminal side cooperation authentication function 25 exchanges predetermined information with the KS side cooperation authentication function 41 (described later) of the authentication key relay type keystore 40 on the terminal 20 side. Note that "KS" is an abbreviation of Key Store. The terminal side cooperative authentication function 25 uses the authentication module authentication public key PK3. The terminal side cooperation authentication function 25 can encrypt the information to be exchanged (the details will be described later).
Authentication module authentication public key PK3 is a public key used when authenticating the authentication module 30 (details will be described later).
The terminal side cooperation authentication function 25 may be mounted on the OS side (Operating System: operating system, not shown) of the terminal 20 or may be mounted on the authentication module 30 side.

  The screen unlocking function 26 unlocks the screen of the terminal 20. The screen lock is a function to require the user to input a password or pattern in order to display a predetermined screen (for example, a home screen) after powering on the terminal 20 or after returning from the sleep state. The screen lock release function 26 may perform the process of setting the screen lock.

  The OS account management function 27 enables the OS (Operating System: operating system, not shown) of the terminal 20 to manage the user's account. The OS account management function 27 includes account management information 28. The account management information 28 is information managed by the OS of the terminal 20 in association with various values for managing the account of the user. Details of the account management information 28 will be described later.

The OS key processing storage area R2 manages various types of keys stored by the OS of the terminal 20. In the OS key processing storage area R2, an authentication module assertion key AK2 and a symmetric key SYK1 for each terminal-side authentication module are stored.
The authentication module assertion key AK2 is a common key that encrypts and decrypts assertions of user authentication.
The symmetric key SYK1 for each terminal-side authentication module is a symmetric key prepared for each authentication module 30 on the terminal 20 side.
The OS key processing storage area R2 is preferably a module having tamper resistance and capable of processing related to a key (key generation, signature verification, certificate generation, encryption, decryption, etc.). However, as long as key storage and key processing are performed only within a limited area, implementation using software or the like may be used.

<Authentication module>
The authentication module 30 is an authentication device for authenticating the user of the terminal 20. The authentication module 30 includes an authentication determination module 31 and a key processing storage area R1.
The authentication determination module 31 permits access to the key processing storage area R1 if the information presented by the user matches the Credential in the user authentication using the Credential registered in advance.
The key processing storage area R1 manages various types of keys stored by the authentication module 30. In the key processing storage area R1, a secret key SK2 for metadata service and an authentication module assertion key AK1 are stored.
The metadata service private key SK 2 is a secret key for the authentication module 30 to use the information 3 of the authentication module of the metadata service 1.
The authentication module assertion key AK1 is a common key that encrypts and decrypts an assertion of user authentication.
The key processing storage area R1 is preferably a module having tamper resistance and capable of processing related to a key (key generation, signature verification, certificate generation, encryption, decryption, and the like). However, as long as key storage and key processing are performed only within a limited area, implementation using software or the like may be used.

<Authentication Key Relay Keystore>
The authentication key relay type key store 40 is a server for storing keys such as the WEB service authentication secret key SK1 online (on the Internet side). The authentication key relay type key store 40 includes the KS side cooperative authentication function 41, a user management DB 42, an account management WEB application 43, a tamper resistant area R3, and a server certificate CE1.

The KS side cooperative authentication function 41 exchanges predetermined information with the terminal side cooperative authentication function 25 of the terminal 20 on the authentication key relay type keystore 40 side. The KS side cooperative authentication function 41 can encrypt the information to be exchanged (the details will be described later).
The user management DB 42 stores information on the user of the terminal 20.
The account management WEB application 43 manages the information stored in the user management DB 42 by reading or rewriting.

The tamper resistant area R3 manages various kinds of keys stored by the authentication module 30. In the key processing storage area R1, a WEB service authentication secret key SK1, an authentication module authentication secret key SK3, a server secret key SK4, and a symmetric key SYK2 for each KS-side authentication module are stored.
The WEB service authentication secret key SK1 is a secret key used to authenticate the user of the terminal 20 using the WEB service. The secret key SK1 for web service authentication is paired with the public key PK1 for web service authentication.
Authentication Module Authentication Secret Key SK3 is a secret key used when authenticating the authentication module 30 (details will be described later). Authentication module authentication secret key SK3 is paired with authentication module authentication public key PK3. As shown in FIG. 1, the key ownership is realized such that the terminal 20 has the authentication module authentication public key PK3 and the authentication key relay type keystore 40 has the authentication module authentication secret key SK3.
The server private key SK4 is a private key used for the signature shown in the server certificate CE1.
The symmetric key SYK2 for each KS-side authentication module is a symmetric key prepared for each authentication module 30 on the authentication key relay type keystore 40 side.
The tamper resistant region R3 is preferably a module that is tamper resistant and is capable of key processing (key generation, signature verification, certificate generation, encryption, decryption, etc.). However, as long as key storage and key processing are performed only within a limited area, implementation using software or the like may be used.

  The server certificate CE1 is an electronic certificate issued by the certificate authority 50, and has signature data of a key / certificate issuer necessary for encrypting information / transmission information of the WEB site owner.

<Metadata service>
The metadata service 1 manages information on authentication modules for which various types exist as information 3 on the authentication modules. Details of authentication module information 3 will be described later.
The metadata service 1 stores the information 3 of the authentication module using the public key for metadata service PK2. The FIDO server 15 of the web service 10 can refer to the information 3 of the authentication module. The authentication key relay type keystore 40 can refer to the information 3 of the authentication module. The public key PK2 for metadata service is paired with the secret key SK2 for metadata service.

<Certificate Authority>
The certificate authority 50 is an entity that issues a digital public key certificate to another party. The certificate authority 50 has a server certificate CE2 and a server public key PK4.
The server certificate CE2 is equivalent to the server certificate CE1.
The server public key PK4 is a secret key used for the signature shown in the server certificate CE1. The server's public key PK4 is paired with the server's secret key SK4.

[Data retention format]
Next, the data holding format will be described.
<Information of authentication module of metadata service>
FIG. 2 is a structural diagram of information 3 of the authentication module of the metadata service 1.
As shown in FIG. 2, the information 3 of the authentication module includes, for each authentication module model ID (3a), an authentication method 3b, a public key ID for metadata service (3c), an implementation form 3d of an authentication module, and a key processing storage area. , The key storage area 3f, and the authentication accuracy 3g. The present embodiment is characterized in that the information 3 of the authentication module has a key storage area 3f surrounded by a thick frame in FIG.

  The authentication module model ID (3a) includes an authentication method 3b, a public key ID (3c) for metadata service, an implementation form 3d of an authentication module, an implementation form 3e of a key processing storage area, a key storage area 3f, and an authentication accuracy 3g. Is an identifier of a specification (model) of the authentication module 30 defined by The authentication module model ID (3a) can be represented by, for example, a nine-digit alphanumeric string such as 1111 # aaaa, 0000 # dddd,.

The authentication method 3 b is a name of an authentication method adopted by the authentication module 30.
The metadata service public key ID (3c) is an identifier of the metadata service public key PK2 associated with the corresponding authentication module model.

The implementation 3 d of the authentication module and the implementation 3 e of the storage area of the key are implemented by hardware or software. Hardware implementations have a higher security level than software implementations.
The key storage area 3f specifies the storage place of the secret key SK1 for WEB service authentication, and in this embodiment, it is in the authentication module 30 (specifically, the key processing storage area R1) or the authentication key relay type key store (Specifically, it is one of the tamper resistant region R3). By setting the key storage area 3f in the information 3 of the authentication module, the WEB service 10 can select the authentication module 30 that satisfies the requirements for the authentication of the WEB service 10 itself. Specifically, the provider of the WEB site can select an authentication method that can satisfy the security level required for providing the WEB service 10. In addition, it is possible to meet the authentication requirements of various web services that require different security levels.

  The authentication accuracy 3g can be determined from the authentication module model. For example, the PIN entry is a five digit number. The accuracy of biometric authentication systems such as fingerprint authentication and iris authentication is evaluated by a combination of FRR (False Rejection) and FAR (False Acceptance).

  Information 3 of the authentication module shown in FIG. 2 is an example, and part of the above information can be deleted or other information can be added.

[Information held by the terminal]
Next, information held by the terminal 20 will be described. Specifically, the information held by the terminal 20 is authentication management information 23 and account management information 28.
FIG. 3 is a structural diagram of information held by the terminal. It is shown as a tree structure in FIG. In the description of FIG. 3 (and the description of FIG. 4 described later), when “ID of xx” and “ID of yy” are connected by a line, “1... 1” attached to the line is one xx Indicates that one yy ID corresponds to the ID of. In addition, when “ID of xx” and “ID of yy” are connected by a line, “1... N (n is an integer of 2 or more)” attached to the line is a plural number for one ID of xx Indicates that the ID of yy corresponds.

<Authentication Management Information>
As shown in FIG. 3A, the authentication management information 23 held by the terminal 20 includes an application ID (23a) of the WEB service, a user ID (23b) of the WEB service, and an authentication module model ID (23c). Web service authentication private key ID (23d), authentication module authentication public key ID (23e), authentication key relay type key store user ID (23f), authentication key relay type key store URL (Uniform) And Resource Locator (23 g).

  The application ID (23a) of the web service is an identifier of the web service application 13 of the web service 10, and is defined by FIDO. For example, the application ID (23a) of the web service can be, for example, the URL of the web service 10 or a hash value of the URL. The application ID (23a) of the web service is located at the highest level, and corresponds to the user ID (23b) of the web service of the next lower one with "1 ... n" (the web service user ID (23b) is "n Equivalent to (multiple)

  The user ID (23b) of the web service is an identifier of a user (registered in the user management DB 14) who uses the web service 10. The user ID (23b) of the web service corresponds to the one lower authentication module ID (23c) with "1 ... n" (the authentication module ID corresponds to "n (plural)"). In addition, the user ID (23b) of the web service corresponds to the user ID (23f) of the authentication key relay type key store of one lower rank with "1 ... 1".

  The authentication module model ID (23c) is equivalent to the authentication module model ID (3a) (see FIG. 2) of the information 3 of the authentication module. The authentication module model ID (23c) corresponds to the ID (23d) of the secret key for WEB service authentication with "1 ... n" (The ID (23d) of the secret key for WEB service authentication corresponds to "n (plurality)" ). In addition, the authentication module model ID (23c) corresponds to the ID (23e) of the public key for authentication module authentication one lower than that of the authentication module model ID (23c) with "1 ... 1".

The ID (23d) of the secret key for web service authentication is an identifier of the secret key SK1 for web service authentication.
The ID (23e) of the authentication module authentication public key is an identifier of the authentication module authentication public key PK3.

The user ID (23f) of the authentication key relay type keystore is an identifier of a user (registered in the user management DB 42) using the authentication key relay type keystore 40. The user ID (23f) of the authentication key relay type key store corresponds to the URL (23g) of the authentication key relay type key store lower by one than "1".
The URL (23g) of the authentication key relay type keystore indicates the location of the authentication key relay type keystore 40.

  The authentication management information 23 shown in FIG. 3A is an example, and part of the above information (ID) can be deleted or other information can be added.

<Account Management Information>
Further, as shown in FIG. 3B, the account management information 28 held by the terminal 20 includes the OS user account (28a), the authentication module assertion key ID (28b), and the symmetric key for each terminal-side authentication module. It has an ID (28c) and an ID (28d) of an authentication module authentication key pair.

  The OS user account (28a) is an account generated for the user of the terminal 20, and corresponds to the account 11 of the web service 10. The OS's user account (28a) is located at the top, and one lower subordinate authentication module assertion key ID (28b) corresponds with "1 ... n" (the authentication module assertion key ID (28b) is "n (multiple Equivalent)).

The authentication module assertion key ID (28b) is an identifier of the authentication module assertion key AK2. The authentication module assertion key ID (28b) corresponds to the symmetric key ID (28c) of each of the terminal-side authentication modules immediately below it by "1... 1".
The symmetric key ID (28c) for each terminal-side authentication module is an identifier of the symmetric key SYK1 for each terminal-side authentication module. The symmetric key ID (28c) of each terminal-side authentication module corresponds to the ID (28d) of the authentication module authentication key pair one lower than that of the terminal authentication module by "1... 1".
The ID (28d) of the authentication module authentication key pair is an identifier of the authentication module authentication key (PK3, SK3).

  The account management information 28 shown in FIG. 3B is an example, and part of the above information (ID) can be deleted or other information can be added.

[Information held by authentication key relay type keystore side]
Next, information held by the authentication key relay type keystore 40 will be described. Specifically, the information held by the authentication key relay type keystore 40 is information of the user management DB 42.
FIG. 4 is a structural diagram of information of the user management DB held by the authentication key relay type keystore. It is shown as a tree structure in FIG.

<Information of user management DB>
As shown in FIG. 4, the user management DB 42 includes a user ID (42a) of an authentication key relay type keystore, an authentication module model ID (42b), an ID (42c) of an authentication module authentication public key, and the KS side. Symmetrical key ID (42d) for each authentication module, ID (42e) for authentication module authentication private key, ID (42f) for WEB service authentication private key, Web service user ID (42g), Web service And the application ID (42h) of

The user ID (42 a) of the authentication key relay type key store is an identifier of the user (registered in the user management DB 42) using the authentication key relay type key store 40, and the authentication key relay type key store of the authentication management information 23 It is equivalent to the user ID (23f).
The user ID (42 a) of the authentication key relay type keystore corresponds to the authentication module model ID (42 b) of one lower rank with “1... 1”.
In addition, the user ID (42a) of the authentication key relay type key store corresponds to the ID (42c) of the public key for authentication module authentication of one lower rank with "1 ... n" (ID of public key for authentication module authentication (42c) corresponds to "n (plurality)".
In addition, the user ID (42a) of the authentication key relay type key store corresponds to the ID (42f) of the WEB service authentication secret key that is lower by one than "1 ... n" (ID of the WEB service authentication secret key) (42f) corresponds to "n (plurality)".

  The authentication module model ID (42b) is equivalent to the authentication module model ID (3a) (see FIG. 2) of the information 3 of the authentication module.

  The ID (42c) of the authentication module authentication public key is an identifier of the authentication module authentication public key PK3, and is equivalent to the ID (23e) of the authentication module authentication public key of the authentication management information 23. The ID (42c) of the authentication module authentication public key corresponds to the symmetric key ID (42d) of each KS-side authentication module with "1... 1".

The symmetric key ID (42d) for each KS-side authentication module is an identifier of the symmetric key SYK2 for each KS-side authentication module. The symmetric key ID (42d) of each KS-side authentication module corresponds to the ID (42e) of the authentication module authentication private key with "1... 1".
The ID (42e) of the authentication module authentication private key is an identifier of the authentication module authentication private key SK3.

  The ID (42f) of the secret key for WEB service authentication is an identifier of the secret key SK1 for WEB service authentication, and is equivalent to the ID (23d) of the secret key for WEB service authentication in the authentication management information 23. The ID (42f) of the secret key for web service authentication corresponds to the user ID (42g) of the web service lower in level by "1 ... 1".

  The web service user ID (42 g) is an identifier of a user (registered in the user management DB 14) who uses the web service 10 and is equivalent to the web service user ID (23 b) of the authentication management information 23. The user ID (42g) of the web service corresponds to the application ID (42h) of the web service under the one lower level with "1 ... 1".

  The application ID (42 h) of the web service is an identifier of the web service application 13 of the web service 10, and is equivalent to the application ID (23 a) of the web service of the authentication management information 23. The application ID (42h) of the web service can be, for example, the URL of the web service 10 or a hash value of the URL.

  The user management DB 42 shown in FIG. 4 is an example, and can delete part of the above information (ID) or add other information.

«Processing»
Next, processing executed by the authentication system of the present embodiment will be described. In making this explanation, the following matters are assumed.
The terminal 20 is a smart phone and includes an authentication module 30. The smartphone can perform, for example, fingerprint authentication. The terminal 20 may be a PC or a tablet. The authentication module 30 may be mounted on the terminal 20 or may be detachably attached to the terminal 20.
The smartphone user and the web service user are the same person (user U).
-The smart phone has a screen lock function, and the use of the smart phone becomes possible after the screen lock is released.
The authentication device for the screen unlocking function of the smartphone and the authentication device of the authentication module can be shared.

  The process to be executed by the authentication system proceeds in the order of (1) scenario A advance setting, (2) scenario B initial registration, (3) scenario C registration on the WEB site, and (4) scenario D authentication on the WEB site And will be individually described below.

[(1) Scenario A advance setting]
In scenario A, screen lock release setting and authentication module setting are performed.
As shown in FIG. 5, the process of scenario A starts from step A1.

In step A1, the user U operates the terminal 20, and a request for screen lock release setting is input to the screen lock release function 26 and the OS account management function 27.
Next, in step A2, the OS account management function 27 creates an account of the user U. The creation of an account at this stage is essential when the terminal 20 is a PC.

  Next, in step A3, the screen lock release function 26 sets screen lock release. For example, when the terminal 20 is a smart phone, a PIN code or pattern is set or a fingerprint is registered as a credential for screen lock release (Credential). When the terminal 20 is a PC, a password is registered as the screen lock release credential.

Next, in step A4, the OS account management function 27 associates the created account with the set or registered screen lock release. The associated information may be stored in account management information 28 (FIG. 1).
Next, in step A5, the screen lock release function 26 and the OS account management function 27 output a response (OK) of the screen lock release setting to the user U. Specifically, screen display and sound output that the screen lock release setting has been completed are performed.

Next, in step A6, the user U operates the terminal 20, and a request for setting an authentication module is input to the FIDO client 22 and the authentication module driver 24 via the terminal side cooperation authentication function 25.
Next, in step A7, the FIDO client 22 and the authentication module driver 24 output the user authentication credential request to the user U via the authentication module 30. Specifically, a screen display prompting presentation of the credential and an audio output are performed.

Next, at step A8, the user U operates the terminal 20, and the authentication module 30 is input such that the user authentication credentials are presented.
Next, in step A9, the authentication module 30 registers the input user authentication credential in the authentication determination module 31. When the registration of the credential is completed, the authentication module 30 generates an authentication module model ID corresponding to the credential.

Next, in step A10, the authentication module 30 notifies the FIDO client 22 and the authentication module driver 24 of completion (OK) of registration of the credential, and transmits the generated authentication module model ID.
Next, in step A11, the FIDO client 22 and the authentication module driver 24 request the OS account management function 27 for an authentication module assertion key via the terminal side cooperative authentication function 25.
Next, in step A12, the OS account management function 27 generates a symmetric key SYK1 for each terminal-side authentication module in the OS key processing storage area R2.

  Next, in step A13, the terminal 20 executes an ECDHE (Diffie-Hellman key exchange) -ECDSA (Elliptic Curve Digital Signature Algorithm) key sharing algorithm across the terminal 20 and the authentication module 30, and a key processing storage area The authentication module assertion key AK1 is generated in R1, and the authentication module assertion key AK2 is generated in the OS key processing storage area R2. When the ECDHE-ECDSA key sharing algorithm is used, the secret key can be shared securely even if the terminal-side cooperative authentication function 25 is implemented on the authentication module 30 side. However, the key sharing algorithm may be another method such as RSA (Rivest-Shamir-Adleman) method. Alternatively, the common key (authentication module assertion key AK1, AK2) may be generated in the OS key processing storage area R2, and the authentication module assertion key AK1 may be sent to the key processing storage area R1 of the authentication module 30.

  Next, in step A14, the OS account management function 27 adds the symmetric key SYK1 for each terminal-side authentication module, the authentication module assertion key AK2, and the authentication module model ID to the account management information 28 (FIG. 1) of the OS. Associate with and save. Such storage means that the setting of the authentication module is completed. As a result, by the authentication on the screen lock release of the terminal 20, the symmetric key SYK1 and the authentication module assertion key AK2 for each terminal-side authentication module of the logged-in account become available.

  Next, in step A15, the OS account management function 27 directs the response (OK) of the setting of the authentication module 30 to the user U via the terminal side cooperation authentication function 25, the FIDO client 22, and the authentication module driver 24. Output. Specifically, screen display and voice output that the setting of the authentication module 30 is completed are performed.

Thus, the process of scenario A is completed.
According to scenario A, it is possible to realize screen lock release setting and authentication module setting.

[(2) Scenario B initial registration]
In scenario B, the authentication key relay type key store 40 and the authentication module 30 carry an authentication module authentication key.
As shown in FIG. 6, the process of scenario B starts from step B1.

In step B1, the user U operates the terminal 20, and a screen lock release instruction is input to the screen lock release function 26.
Next, in step B2, the OS account management function 27 permits access to the OS key processing storage area R2 corresponding to the user account. That is, the authentication upon unlocking the screen of the terminal 20 is successful, and the symmetric key SYK1 and the authentication module assertion key AK2 for each terminal-side authentication module of the logged-in account become available.

  Next, in step B3, the OS account management function 27 outputs to the user that the screen lock release is successful (OK). Specifically, screen display or voice output indicating that access to the OS key processing storage area R2 corresponding to the user account is permitted is performed.

  Next, in step B4, the user U operates the terminal 20 to access the account management WEB application 43 of the authentication key relay type key store 40 via the browser application 21. This access can use, for example, a Secure Sockets Layer (SSL) / Transport Layer Security (TSL) connection. As a premise, it is assumed that the (user U's) account possessed by the authentication key relay type keystore 40 has been created in advance. Authentication of the account on the authentication key relay type keystore 40 side can execute authentication by an ID, a password or the like.

Next, in step B5, the user U operates the terminal 20, and a request for authentication module registration is input to the account management WEB application 43. For example, the “authentication module registration” button is displayed on the browser screen, and is input by pressing the button.
Next, in step B6, the account management WEB application 43 transmits a request for authentication module registration (equivalent to the request input by the user U in step B5) to the KS side cooperative authentication function 41.

Next, in step B7, the KS side cooperative authentication function 41 requests the authentication key relay type key store 40 to generate an authentication module authentication key in the tamper resistant area R3.
Next, in step B8, the authentication key relay type key store 40 generates an authentication module authentication key in the tamper resistant area R3, that is, an authentication module authentication public key PK3 and an authentication module authentication private key SK3. Do.
Next, in step B9, the authentication key relay type key store 40 signs the authentication module authentication public key PK3 in the tamper resistant region R3 using the server secret key SK4.

Next, in step B10, the authentication key relay type key store 40 takes out the signed authentication module authentication public key PK3 from the tamper resistant area R3 and sends it to the KS side cooperative authentication function 41.
Next, in step B11, the KS side cooperative authentication function 41 sends the signed authentication module authentication public key PK3 to the account management WEB application 43.
Next, in step B12, the account management WEB application 43 sends the signed authentication module authentication public key PK3 to the terminal side cooperative authentication function 25 via the browser application 21.

Next, in step B13, the terminal side cooperative authentication function 25 verifies the signature of the signed public key for authentication module authentication PK3.
If the signature is authentic (OK), the terminal side cooperation authentication function 25 transmits the authentication request to the user U via the FIDO client 22, the authentication module driver 24 and the authentication module 30 in step B14. Output toward Specifically, a screen display prompting presentation of the credential and an audio output are performed.

  As shown in FIG. 7, next, in step B15, the user U operates the terminal 20, and the authentication module 30 is input so as to present user authentication credentials.

Next, in step B16, the authentication determination module 31 verifies the user authentication using the presented credentials, that is, determines whether the user U is the person himself or herself.
If the user U is the person (OK), in step B17, the authentication determination module 31 uses the secret key SK2 for metadata service to use the authentication module model ID 301 (see FIG. 5) in the key processing storage area R1. The authentication module model ID generated in step A10, and corresponds to the authentication module model ID 23c included in the authentication management information 23 (FIG. 3A).

Next, in step B18, the authentication determination module 31 generates an assertion 302 and encrypts the signed authentication module model ID 301 and the assertion 302 in the key processing storage area R1 using the authentication module assertion key AK1. .
Next, in step B19, the authentication module 30 authenticates the OS account management function 27 via the FIDO client 22, the authentication module driver 24, and the terminal-side cooperative authentication function 25 into an authentication module model ID 301. And send the assertion 302.

Next, in step B20, the OS account management function 27 decrypts the authentication module model ID 301 and the assertion 302 encrypted in the OS key processing storage area R2 with the authentication module assertion key AK2, and performs assertion verification. do. In this embodiment, it is assumed that the verification result of the assertion is good.
Next, in step B21, the OS account management function 27 notifies the terminal side cooperative authentication function 25 that the verification result of the assertion is good (authentication OK) and the decrypted signature The authentication module model ID 301 is transmitted.

Next, in step B22, the terminal side cooperation authentication function 25 transmits the signed authentication module model ID 301 to the KS side cooperation authentication function 41 via the browser application 21 and the account management WEB application.
Next, in step B23, the KS side cooperative authentication function 41 refers to the metadata service 1 and acquires a public key PK2 for metadata service.
Next, in step B24, the KS side cooperative authentication function 41 verifies the signature of the signed authentication module model ID 301 using the metadata service public key PK2.

  As shown in FIG. 8, if the signature is authentic (signature verification OK) (step B25), the KS side cooperative authentication function 41 determines the account management WEB application 43 and the browser application at step B26. 21 notifies the terminal side cooperative authentication function 25 that the signature is authentic (OK). At step B26, information on the user U is registered in the user management DB 42 (see FIG. 4).

Next, in step B27, the terminal side cooperative authentication function 25 sends the authentication module authentication public key PK3 (whose signature is determined to be authentic in step B13 (FIG. 6)) into the OS key processing storage area R2. .
Next, in step B28, the OS account management function 27 sets the public key PK3 for authentication module authentication in the OS key processing storage area R2 to the symmetric key SYK1 for each terminal-side authentication module (see step A12 in FIG. 5). Encrypt using. Also, the OS account management function 27 transmits the encrypted authentication module authentication public key PK3 to the terminal side cooperative authentication function 25.

  Next, in step B29, the terminal side cooperation authentication function 25 uses the OS of the terminal 20 with the authentication module authentication public key PK3 received from the OS account management function 27 and the URL of the KS side cooperation authentication function 41. Handle and store in association with the (user U's) account. As a result, the authentication module authentication public key PK3 is associated with the account logged in by the authentication upon unlocking of the terminal 20. Also, such storage means that the registration of the authentication module 30 is completed. Authentication for access to authentication key relay type keystore 40 is executed by screen lock release by associating the key necessary for screen lock release and access to authentication key relay type key store 40 with the account of screen lock. can do.

Next, in step B30, the terminal side cooperation authentication function 25 notifies the account management WEB application 43 via the browser application 21 that the terminal 20 has completed the registration of the authentication module 30 (OK). Do. The account management WEB application 43 updates the user management DB 42 so as to reflect the registration of the authentication module 30.
Next, in step B31, the account management WEB application 43 notifies the browser application 21 that the registration of the authentication module 30 has been completed on the authentication key relay type key store 40 side. As a result, the user U who is looking at the screen of the terminal 20 can recognize that the registration of the authentication module 30 is completed as a response to the authentication module registration request (step B5).

  On the other hand, if the signature is not authentic (signature verification NG) (step B32), in step B33, the KS side cooperative authentication function 41 receives the account management WEB application 43 and the browser application 21 via The terminal side cooperative authentication function 25 is notified that the signature is not authentic (NG).

Next, in step B34, the terminal side cooperative authentication function 25 deletes the authentication module authentication public key PK3 (whose signature is determined to be authentic in step B13 (FIG. 6)).
Next, in step B35, the terminal side cooperation authentication function 25 notifies the account management WEB application 43 that the deletion of the authentication module authentication public key PK3 has been completed on the terminal 20 side via the browser application 21. Notice.
Next, in step B36, the account management WEB application 43 notifies the browser application 21 that the deletion of the authentication module authentication public key PK3 has been completed on the authentication key relay type key store 40 side. As a result, the user U who is looking at the screen of the terminal 20 can recognize that the registration of the authentication module 30 has failed as a response to the request for authentication module registration (step B5).

Thus, the process of scenario B is completed.
According to scenario B, the authentication key relay type keystore 40 and the authentication module 30 carry an authentication module authentication key (the authentication key relay type keystore 40 has the authentication module authentication private key SK3 and the authentication module 30 (Encrypted) authentication module authentication public key PK3).

[(3) Register on Scenario C WEB site]
In scenario C, the authentication key relay type key store 40 generates the web service authentication secret key SK1 and shares the key with the web service 10 side.
As shown in FIG. 9, the process of scenario C starts from step C1.

In step C1, the user U operates the terminal 20, and an instruction for screen lock release is input to the screen lock release function 26.
Next, in step C2, the OS account management function 27 permits access to the OS key processing storage area R2 corresponding to the user account. That is, the authentication for access to the authentication key relay type keystore 40 is completed by the screen lock release.

  Next, in step C3, the OS account management function 27 outputs to the user that the screen lock release is successful (OK). Specifically, a screen display or voice output indicating that access to the OS key processing storage area R2 corresponding to the user account is permitted and that access to the authentication key relay type key store 40 is permitted are made. Is done.

  Next, in step C4, the user U operates the terminal 20, accesses the WEB site of the WEB service 10 via the browser / application 21, and logs in (for new registration). In FIDO UAF 1.0, the WEB service 10 side is supposed to create the account of the user U in advance, and in this embodiment it is supposed to be created in advance, and login on the WEB site is enabled. .

  Next, in step C5, the user U operates the terminal 20 and requests the WEB service 10 to switch the authentication method of the user U's account to the FIDO authentication method via the browser application 21. It is input.

Next, in step C6, the WEB service 10 sends a FIDO registration request (a request for FIDO registration) to the authentication module 30 via the browser / application 21, the FIDO client 22, and the authentication module driver 24. Send.
Next, in step C7, the authentication module 30 outputs a request for user authentication to the user U. Specifically, screen display or audio output is performed to prompt presentation of credentials used for user authentication.

Next, in step C8, the user U operates the terminal 20, and the authentication module 30 is input so that the user authentication credential is presented.
Next, in step C9, the authentication determination module 31 verifies the user authentication using the input credentials, that is, determines whether the user U is the person himself or herself.
If the user U is the person (OK), the authentication determination module 31 generates an assertion 303 in step C10, and uses the authentication module assertion key AK1 to execute the assertion 303 in the key processing storage area R1. And encrypt the FIDO registration request 304 (corresponding to the request of step C6).

Next, in step C11, the authentication module 30 transmits the encrypted assertion 303 and FIDO registration request 304 to the FIDO client 22 and the authentication module driver 24, and also generates a WEB service authentication key generation request. Send. The WEB service authentication key is the WEB service authentication public key PK1 and the WEB service authentication private key SK1.
Next, in step C12, the FIDO client 22 and the authentication module driver 24 transmit the encrypted assertion 303 and FIDO registration request 304 to the terminal side cooperative authentication function 25, and also use the WEB service authentication key. Send a generation request.

Next, in step C13, the terminal side cooperative authentication function 25 transmits a request for generation of a common key for encryption to the OS account management function 27, and the encrypted assertion 303 (encrypted A FIDO registration request 304 is also included.) And an encrypted authentication module authentication public key PK3 (stored in step B29 in FIG. 8).
Next, in step C14, the OS account management function 27 decrypts the encrypted assertion 303 and FIDO registration request 304 in the OS key processing storage area R2 using the authentication module assertion key AK2, and performs assertion verification. do. In this embodiment, it is assumed that the verification result of the assertion is good (OK).

As shown in FIG. 10, next, in step C15, the OS account management function 27 generates a common key CK according to, for example, AES (Advanced Encryption Standard). Further, the OS account management function 27 generates Challenge 201 (challenge) and encrypts it with the common key CK. The Challenge 201 is a random number sequence used for known challenge / response authentication.
Next, in step C16, the OS account management function 27 decrypts the encrypted authentication module authentication public key PK3 using the symmetric key SYK1 (see step A12 in FIG. 5) for each terminal-side authentication module. The common key CK is encrypted using the decrypted authentication module authentication public key PK3.

  Next, in step C17, the OS account management function 27 transmits the encrypted common key CK to the KS side cooperative authentication function 41 of the authentication key relay type key store 40 via the terminal side cooperative authentication function 25. Then, the encrypted Challenge 201 is sent, and the KS side cooperative authentication function 41 stores the encrypted common key CK and the encrypted Challenge 201 in the tamper resistant area R3.

Next, in step C18, the authentication key relay type key store 40 decrypts the common key CK using the authentication module authentication secret key SK3 in the tamper resistant region R3.
Next, in step C19, the authentication key relay type key store 40 decrypts the Challenge 201 using the decrypted common key CK in the tamper resistant region R3, and calculates a Response 401. Response 401 is a random number sequence used for known challenge / response authentication. Further, the authentication key relay type key store 40 encrypts the response 401 with the common key CK.

Next, in step C20, the authentication key relay type key store 40 encrypts the OS account management function 27 via the KS side cooperation authentication function 41 and the terminal side cooperation authentication function 25 of the terminal 20. Send the response 401 that has been sent.
Next, at step C21, the OS account management function 27 decrypts and verifies the encrypted Response 401 using the common key CK in the OS key processing storage area R2. In this embodiment, it is assumed that the verification result of Response 401 is good (OK).

Next, in step C22, the OS account management function 27 encrypts the FIDO registration request 304 using the common key CK.
Next, in step C23, the OS account management function 27 transmits the encrypted FIDO registration request 304 to the KS side cooperative authentication function 41 of the authentication key relay type key store 40 via the terminal side cooperative authentication function 25. The KS side cooperative authentication function 41 stores the encrypted FIDO registration request 304 in the tamper resistant area R3.

Next, in step C24, the authentication key relay type key store 40 decrypts the encrypted FIDO registration request 304 using the common key CK (decrypted in step C18) in the tamper resistant region R3. Do. Then, the authentication key relay type key store 40 carries out the processing of the FIDO registration request 304, and generates the FIDO registration response 402 as the processing result.
Next, in step C25, the authentication key relay type key store 40 stores the WEB service authentication key (pair) in the tamper resistant area R3, that is, the WEB service authentication public key PK1 and the WEB service authentication private key SK1. Generate

  Next, in step C26, the authentication key relay type key store 40 encrypts the FIDO registration response 402 and the WEB service authentication public key PK1 using the common key CK in the tamper resistant region R3. Further, the KS side cooperative authentication function 41 of the authentication key relay type key store 40 encrypts the FIDO registration response 402 and the encrypted to the OS account management function 27 via the terminal side cooperative authentication function 25 of the terminal 20. Send the public key PK1 for WEB service authentication. The common key CK of the authentication key relay type keystore 40 may be discarded after the completion of this step.

Next, in step C27, the OS account management function 27 encrypts the FIDO registration response 402 and the WEB service authentication public key PK1 encrypted using the common key CK in the OS key processing storage area R2. Decrypt. The common key CK held by the terminal 20 may be discarded after the completion of this step.
As shown in FIG. 11, next, at step C28, the OS account management function 27 sets the FIDO registration response 402 and the WEB service authentication public key PK1 in the OS key processing storage area R2 to the authentication module assertion key. Encrypt with AK2.

Next, in step C29, the OS account management function 27 encrypts the FIDO registration response 402 to the authentication module 30 via the terminal side cooperation authentication function 25, the FIDO client 22, and the authentication module driver 24. And transmit the public key PK1 for web service authentication.
Next, in step C30, the authentication judgment module 31 decrypts the FIDO registration response 402 and the WEB service authentication public key PK1 encrypted in the key processing storage area R1 using the authentication module assertion key AK1. Do.

Next, in step C31, the authentication determination module 31 uses the secret key SK2 for metadata service to sign the FIDO registration response 402 in the key processing storage area R1.
Next, in step C32, the authentication module 30 sends the signed FIDO registration response 402 and the WEB service authentication public key PK1 to the WEB via the browser / application 21, the FIDO client, and the authentication module driver 24. Send to service 10

Next, in step C33, the WEB service 10 refers to the metadata service 1 and acquires the public key PK2 for metadata service.
Next, in step C34, the web service 10 verifies the signature of the signed FIDO registration response 402 using the public key for metadata service PK2.

  If the signature is authentic (OK), in step C35, the web service 10 associates the web service authentication public key PK1 with the account of the user U (symbol 11 in FIG. 1) and saves it. The storage destination is the key management area 16 (see FIG. 1) of the FIDO server 15 of the web service 10.

  Next, in step C36, the WEB service 10 notifies the browser application 21 that the switch to the FIDO authentication method has been completed. As a result, the user U who is looking at the screen of the terminal 20 can recognize that the authentication method has been switched to the FIDO authentication method as a response to the request for switching to the FIDO authentication method (step C5). In addition, the terminal 20 uses the information included in the notification from the web service 10 in step C36 to execute the authentication management information 23 (see FIG. 3A) related to the user U using the web service 10. Create and memorize.

Thus, the process of scenario C is completed.
According to scenario C, the authentication key relay type key store 40 can generate the web service authentication secret key SK1 and share the key with the web service 10 side. That is, as in the prior art, the WEB service authentication private key SK1 can be held not on the authentication module 30 side but on the WEB service 10 side. As a result, the terminal 20 of the user U can be registered in the WEB site of the WEB service 10.

[(4) Scenario D Authentication on WEB site]
In scenario D, the web service authentication secret key SK1 stored in the authentication key relay type key store 40 is used to log in to the web site of the web service 10.
As shown in FIG. 12, the process of scenario D starts from step D1.

In step D1, the user U operates the terminal 20, and a screen lock release instruction is input to the screen lock release function 26.
Next, in step D2, the OS account management function 27 permits access to the OS key processing storage area R2 corresponding to the user account. That is, the authentication for access to the authentication key relay type keystore 40 is completed by the screen lock release.

  Next, at step D3, the OS account management function 27 outputs to the user that the screen lock release is successful (OK). Specifically, a screen display or voice output indicating that access to the OS key processing storage area R2 corresponding to the user account is permitted and that access to the authentication key relay type key store 40 is permitted are made. Is done.

  Next, in step D4, the user U operates the terminal 20, accesses the WEB site of the WEB service 10 via the browser / application 21, and requests login.

Next, in step D5, the WEB service 10 sends a FIDO authentication request (a request for FIDO authentication) to the authentication module 30 via the browser / application 21, the FIDO client 22, and the authentication module driver 24. Send.
Next, in step D6, the authentication module 30 outputs a request for user authentication to the user U. Specifically, screen display or audio output is performed to prompt presentation of credentials used for user authentication.

Next, in step D7, the user U operates the terminal 20, and the authentication module 30 is input such that the user authentication credentials are presented.
Next, in step D8, the authentication determination module 31 verifies the user authentication using the input credentials, that is, determines whether the user U is the person himself or herself.
If the user U is the person (OK), the authentication determination module 31 generates an assertion 305 in step D9, and uses the authentication module assertion key AK1 to make an assertion 305 in the key processing storage area R1. And encrypt the FIDO authentication request 306 (corresponding to the request of step D5).

Next, in step D10, the authentication module 30 transmits the encrypted assertions 305 and FIDO authentication request 306 to the FIDO client 22 and the authentication module driver 24 and also makes a signature request for the WEB service authentication key. Send. The WEB service authentication key is the WEB service authentication public key PK1 and the WEB service authentication private key SK1.
Next, in step D11, the FIDO client 22 and the authentication module driver 24 transmit the encrypted assertions 305 and the FIDO authentication request 306 to the terminal side cooperative authentication function 25, and the WEB service authentication key. Send a generation request.

Next, in step D12, the terminal side cooperative authentication function 25 transmits a request for generation of a common key for encryption to the OS account management function 27 and the encrypted assertion 303 (encrypted The FIDO authentication request 306 is also included.) And the encrypted authentication module authentication public key PK3 (stored in step B29 in FIG. 8).
Next, in step D13, the OS account management function 27 decrypts the encrypted assertions 305 and FIDO authentication request 306 in the OS key processing storage area R2 using the authentication module assertion key AK2 and performs assertion verification. do. In this embodiment, it is assumed that the verification result of the assertion is good (OK).

As shown in FIG. 13, next, at step D14, the OS account management function 27 generates a common key CK according to, for example, AES. Further, the OS account management function 27 generates Challenge 201 (challenge) and encrypts it with the common key CK.
Next, in step D15, the OS account management function 27 decrypts the encrypted authentication module authentication public key PK3 using the symmetric key SYK1 (see step A12 in FIG. 5) for each terminal-side authentication module. The common key CK is encrypted using the decrypted authentication module authentication public key PK3.

  Next, in step D16, the OS account management function 27 sends the KS side cooperative authentication function 41 of the authentication key relay type key store 40 with the encrypted common key CK via the terminal side cooperative authentication function 25. Then, the encrypted Challenge 201 is sent, and the KS side cooperative authentication function 41 stores the encrypted common key CK and the encrypted Challenge 201 in the tamper resistant area R3.

Next, in step D17, the authentication key relay type key store 40 decrypts the common key CK using the authentication module authentication secret key SK3 in the tamper resistant region R3.
Next, in step D18, the authentication key relay type key store 40 decrypts the Challenge 201 using the decrypted common key CK within the tamper resistant region R3, and calculates a Response 401. Further, the authentication key relay type key store 40 encrypts the response 401 with the common key CK.

Next, in step D19, the authentication key relay type key store 40 encrypts the OS account management function 27 via the KS side cooperation authentication function 41 and the terminal side cooperation authentication function 25 of the terminal 20. Send the response 401 that has been sent.
Next, at step D20, the OS account management function 27 decrypts and verifies the encrypted Response 401 using the common key CK in the OS key processing storage area R2. In this embodiment, it is assumed that the verification result of Response 401 is good (OK).

Next, in step D21, the OS account management function 27 encrypts the FIDO authentication request 306 using the common key CK.
Next, in step D22, the OS account management function 27 transmits the encrypted FIDO authentication request 306 to the KS side cooperation authentication function 41 of the authentication key relay type key store 40 via the terminal side cooperation authentication function 25. The KS side cooperative authentication function 41 stores the encrypted FIDO authentication request 306 in the tamper resistant area R3.

Next, in step D23, the authentication key relay type key store 40 decrypts the encrypted FIDO authentication request 306 using the common key CK (decrypted in step D17) in the tamper resistant region R3. Do. Then, the authentication key relay type key store 40 carries out the processing of the FIDO authentication request 306, and generates the FIDO authentication response 403 as the processing result.
Next, in step D24, the authentication key relay type key store 40 signs the FIDO authentication response 403 in the tamper resistant region R3 using the WEB service authentication private key SK1.

  Next, in step D25, the authentication key relay type key store 40 encrypts the FIDO authentication response 403 using the common key CK in the tamper resistant region R3. Further, as shown in FIG. 13 and FIG. 14, the KS side cooperative authentication function 41 of the authentication key relay type key store 40 sends the OS account management function 27 via the terminal side cooperative authentication function 25 of the terminal 20 Send the encrypted FIDO authentication response 403.

As shown in FIG. 14, next, at step D26, the OS account management function 27 decrypts the encrypted FIDO authentication response 403 using the common key CK in the OS key processing storage area R2. .
Next, in step D27, the OS account management function 27 encrypts the FIDO authentication response 403 with the authentication module assertion key AK2 in the OS key processing storage area R2.

Next, in step D28, the OS account management function 27 encrypts the encrypted FIDO authentication response 403 to the authentication module 30 via the terminal side cooperation authentication function 25, the FIDO client 22, and the authentication module driver 24. Send.
Next, in step D29, the authentication determination module 31 uses the authentication module assertion key AK1 to decrypt the encrypted FIDO authentication response 403 in the key processing storage area R1.

  Next, in step D30, the authentication module 30 transmits a signed FIDO authentication response 403 to the WEB service 10 via the browser / application 21, the FIDO client, and the authentication module driver 24.

  Next, in step D31, the WEB service 10 verifies the signature of the signed FIDO authentication response 403 using the WEB service authentication public key PK1.

  If the signature is authentic (OK), in step D32, the WEB service 10 completes the authentication of FIDO for the browser application 21 (OK), and login to the WEB site is permitted (OK). Notice that it is OK. As a result, as a response to the user authentication request (step D6), the user U who is looking at the screen of the terminal 20 can recognize that the FIDO authentication is completed and login to the WEB site is permitted. .

Thus, the process of scenario D is completed.
According to scenario D, it is possible to log in to the web site of the web service 10 using the secret key SK1 for web service authentication stored in the authentication key relay type key store 40.

[Secured Configuration of Authentication Key Relay Keystore]
A variety of attacks are considered on the Internet side, and there is a possibility that an internal function unit or application of the authentication key relay type keystore 40 may be hijacked and an unauthorized operation may be performed. For example, the user ID (42a) of the authentication key relay type key store for identifying the user of the authentication key relay type key store 40 has a predetermined relationship with the WEB service authentication secret key SK1 and the authentication module authentication secret key SK3. If an application that uses this predetermined relationship is hijacked (see FIG. 4), unauthorized rewriting may occur.

In view of such circumstances, the association between the user ID (42a) of the authentication key relay type keystore, the WEB service authentication secret key SK1 and the authentication module authentication secret key SK3 is not on the Internet side but on the local network side. To do.
Specifically, as shown in FIG. 15A, the authentication system 100 of the present embodiment has the same function as the authentication key relay type keystore 40 (first keystore) disposed on the Internet side. The authentication key relay type keystore 40-1 (second keystore) is disposed on the local network side. Authentication key relay type key store 40-1, KS side cooperation authentication function 41-1, user management DB 42-1, account management WEB application 43-1 and tamper resistant area R3-1 are respectively authentication key relay type key store 40 are equivalent to the KS side cooperative authentication function 41, the user management DB 42, the account management WEB application 43, and the tamper resistant area R3.

  The local network is, for example, a network uniquely constructed by a business operator who is required to perform strict identity verification such as a communication carrier network of a communication company or a credit card company. Such a local network is isolated from the outside, and can be said to have a high security characteristic that does not receive an unspecified number of accesses from the outside.

  The account management WEB application 43-1 of the authentication key relay type key store 40-1 has functions of registration, addition, change, and deletion of the terminal 20. The account management WEB application 43-1 uses these functions to associate the user ID with the ID of the authentication module authentication key, and share the key between the terminal 20 and the authentication key relay type key store 40-1. be able to.

  At the initial registration stage of the terminal 20 (see scenario B shown in FIGS. 6 to 8), the authentication key relay type keystore 40-1 replaces the authentication key relay type keystore 40 and the user of the authentication key relay type keystore The association between the ID (42a) and the WEB service authentication private key SK1 and the authentication module authentication private key SK3 is encrypted so as to be encrypted. Specifically, as shown in FIG. 15B, the authentication key relay type keystore 40-1 is information managed by the user management DB 42-1 of the authentication key relay type keystore 40-1 (see FIG. 4). Among them, the user ID (42a) of the authentication key relay type keystore, the authentication module model ID (42b), the ID (42c) of the authentication module authentication public key, and the symmetric key ID (42d) for each KS side authentication module And the ID (42e) of the authentication module authentication secret key in the tamper resistant region R3-1 using the server secret key SK4 of the authentication key relay type key store 40-1 in an integrated manner. The data is encrypted and registered in the user management DB 42-1. Further, as shown in FIG. 15 (b), for the encrypted integral data, the user ID (42a-1) of the authentication key relay type keystore and the authentication module model ID as the data search ID. (42b-1) and the ID (42c-1) of the authentication module authentication public key are added.

  Thereafter, synchronization processing is performed between the user management DB 42-1 of the authentication key relay type keystore 40-1 and the user management DB 42 of the authentication key relay type keystore 40, and the user management DB 42 of the authentication key relay type keystore 40 is performed. Update As a result, the encrypted integrated data is registered in the user management DB 42 of the authentication key relay type keystore 40.

  The authentication key relay type key store 40 decrypts integral data in the tamper resistant area R3 using the server public key PK4. Further, the authentication key relay type key store 40 can confirm that it has been sent from the correct terminal 20 by verifying the decrypted integrated data by using the authentication module authentication secret key SK3.

  As described above, the high security local network side associates the user ID (42a) of the authentication key relay type key store with the WEB service authentication private key SK1 and the authentication module authentication private key SK3. Therefore, unauthorized rewriting of the association can be prevented in advance. Also, even if unauthorized rewriting is performed in the authentication key relay type keystore 40 (the Internet side), the information is illegal as compared with the information of the user management DB 42-1 of the authentication key relay type keystore 40-1. Since rewriting can be determined within the tamper-resistant region R3, as a result, illegal rewriting can be prevented.

With reference to FIG. 16, the continuation of the processing relating to one piece of data will be described. FIG. 16 (a) is the same as FIG. 15 (a).
The account management WEB application 43 of the authentication key relay type key store 40 has functions of registration, authentication, and deletion of the WEB service 10 or WEB site. Using these functions, the account management WEB application 43 associates the user ID of the authentication key relay type key store, the ID of the WEB service authentication private key, and the application ID of the WEB service, or the secret key SK1, Generate SK3.

  Authentication key relay type at the stage of registration of the terminal 20 on the WEB site (see scenario C shown in FIGS. 9 to 11) or at the stage of authentication on the WEB site (see scenario D shown in FIGS. 12 to 14) After decrypting the integral data in the tamper resistant region R3, the key store 40 adds information on the WEB site to the decrypted integral data and registers it in the user management DB 42. Specifically, the authentication key relay type keystore 40 constitutes the decrypted integrated data, the user ID (42a) of the authentication key relay type keystore, the authentication module model ID (42b), and the authentication module authentication The ID of the secret key for WEB service authentication in the partial information including the public key ID (42c), the symmetric key ID (42d) for each KS side authentication module, and the ID (42e) of the authentication module authentication secret key 42f), the web service user ID (42g), and the web service application ID (42h) are associated. As a result, information having the same structure as the information (see FIG. 4) managed by the user management DB 42 is generated. Further, the account management WEB application 43 of the authentication key relay type key store 40 performs generation of the secret key SK1 (scenario C), signature using the secret key SK1 (scenario D) and the like using the generated information.

When the predetermined process is completed, the account management WEB application 43 of the authentication key relay type key store 40 has the same structure as the information managed by the user management DB 42 (see FIG. 4), as shown in FIG. Are encrypted again as integral data using the server's secret key SK4 of the authentication key relay type keystore 40-1 in the tamper resistant region R3, and the encrypted integral data is output to the user management DB 42 And store. At this time, for the encrypted integral data, the user ID (42a-1) of the authentication key relay type keystore, the authentication module model ID (42b-1), and the authentication module as data search IDs. The ID (42c-1) of the public key for authentication is added.
The synchronization process is performed between the user management DB 42 of the authentication key relay type keystore 40 and the user management DB 42-1 of the authentication key relay type keystore 40-1, and the user of the authentication key relay type keystore 40-1 is The management DB 42-1 may be updated.

  As described above, by encrypting the information managed by the user management DB 42 of the authentication key relay type keystore 40, it is possible to prevent the external unauthorized rewrite.

(Summary)
When the apparatus for performing user authentication (terminal 20) is different from the apparatus for storing the secret key SK1 for WEB service authentication (authentication key relay type key store 40), the user authentication result and the secret key SK1 for WEB service authentication As a matter of course, there is no guarantee of the processing order or relationship between the two. However, according to the present embodiment, the user authentication result and the WEB service authentication are performed using the authentication module authentication public key PK3 on the terminal 20 side and the authentication module authentication private key SK3 on the authentication key relay type keystore 40 side. By associating the secret key SK1 with the secret key SK1, the processing order and the relationship between the two can be made unique. Conventionally, when using a secret key, authentication is required, and when using two kinds of secret keys such as the secret key SK3 for authentication module authentication of the certification key relay type key store 40 and the secret key SK1 for web service authentication, It is necessary to authenticate the user for each use of the secret key (that is, perform user authentication twice) and obtain approval in each authentication, but in this method, the key use order is made unique from the user authentication Since it is possible to authenticate the user once. As a result, the operation amount of the user at the time of authentication in the web service 10 can be made the same as in the conventional FIDO authentication method. Therefore, it is possible to detect and prevent an unauthorized operation of directly accessing the authentication key relay type keystore 40 such as impersonation or man-in-the-middle attack, and high security can be realized.
In addition, since the area that can process the key is limited, plaintext can be handled only within a limited area, and even the operator of the authentication key relay type keystore 40 tampers with information, eavesdropping, etc. It is not possible to illegally use transmitted and received information, which contributes to the improvement of security.
Further, since the WEB service authentication private key SK1 does not exist on the terminal 20 side, loss of the private key SK1 by the user can not occur, and interruption of continuous use of the WEB service can be avoided.
Therefore, it is possible to prevent the loss of the key used for the on-line authentication for the web service, and to reliably execute the on-line authentication for the web service.
Note that even if the authentication key relay type keystore 40 is added to the authentication system 100, no special addition or change is required for the FIDO (UAF) protocol between the terminal 20 and the WEB service 10, so the authentication system 100 It is easy to introduce a relay type keystore 40.

  Further, according to the present embodiment, it is possible to introduce a mechanism that enables access to the authentication key relay type key store 40 only when the success of the user authentication by the screen lock release is realized. Therefore, access to the public key PK3 for authentication module authentication from an external application or the like can be restricted, unauthorized use of the key can be prevented, and security can be further improved.

  Further, according to the present embodiment, since the authentication key relay type key store 40-1 disposed on the local network side which strictly manages the information to be held performs initial registration of the user of the terminal 20, the external from the outside Unauthorized operations such as hijacking of functions can be made more difficult, and security can be further improved.

«Others»
(1): In the present embodiment, when the web service 10 registers the user of the terminal 20 (scenario C shown in FIG. 9 to FIG. 11) or when authenticating the user of the terminal attempting to access the web service 10 (Scenario D shown in FIGS. 12 to 13), the terminal 20 has the authentication module authentication public key PK3, and the authentication key relay type key store 40 has the authentication module authentication secret key SK3. , Can be confirmed between the terminal 20 and the authentication key relay type key store 40. As a result of the confirmation, when the cross-holding of keys is not established (when one or both of the public key PK3 and the secret key SK3 are lost), when the web service 10 registers the user of the terminal 20 (scenario C) Or, when authenticating the user of the terminal trying to access the web service 10 (scenario D), the key holding is established between the terminal 20 and the authentication key relay type key store 40 (public key PK3 and secret key Can recover SK3). Briefly, at the stage of scenarios C and D, the initial registration of scenario B (see FIGS. 6 to 8) is executed again.

  From the point of view of preventing unauthorized operation, authentication key relay when terminal 20 accesses authentication key relay type key store 40 in addition to user authentication for WEB service 10 at the time of registration / authentication of WEB service 10 It is also necessary to perform user authentication on the side of the type key store 40. That is, user authentication needs to be performed twice. However, according to the present embodiment, the terminal 20 and the authentication key relay type key store are in the stage of registration of the user in the WEB service 10 or in the stage of authentication of the user of the terminal 20 trying to access the WEB service 10. In order to realize the cross-talking of keys between 40 and 40, the screen unlocking of the terminal 20 doubles as the user authentication on the authentication key relay type key store 40 side, so that after cross-crossing of the keys is established, Only the user authentication for the WEB service 10 can be completed, and the processing load can be reduced.

(2): Of the processes described in the above embodiment, all or part of the process described as being automatically performed may be manually performed, or may be performed manually All or part of the described processing can also be performed automatically in a known manner. In addition to the above, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified.
Further, each component of each device illustrated is functionally conceptual, and does not necessarily have to be physically configured as illustrated. That is, the specific form of the dispersion and integration of each device is not limited to that shown in the drawings, and all or a part thereof is functionally or physically dispersed in any unit depending on various loads, usage conditions, etc. It can be integrated and configured.

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

In addition, it is also possible to realize a technique in which various techniques described in the present embodiment are appropriately combined.
In addition, hardware, software, flowcharts, and the like can be appropriately modified without departing from the spirit of the present invention.

100 authentication system 1 metadata service 3 authentication module information 10 WEB service 20 terminal 23 authentication management information 25 terminal side cooperation authentication function 26 screen unlocking function 27 account management function for OS 28 account management information 30 authentication module 31 authentication judgment module 40 Authentication key relay type key store (key store: first key store)
40-1 Authenticated Key Relay Keystore (Second Keystore)
41 KS side cooperation authentication function 42 user management DB
43 Account management WEB application 50 Certificate authority PK1 WEB service authentication public key SK1 WEB service authentication private key PK2 Metadata service public key SK2 Metadata service private key PK3 Authentication module authentication public key SK3 Authentication module authentication private key PK4 server public key SK4 server private key

Claims (6)

An authentication system in which a terminal including an authentication module for performing user authentication, a web service used by the terminal, and a key store having a predetermined key are communicably connected.
The web service has a web service authentication public key used for authentication for the terminal to access the web service,
The key store encloses a secret key for web service authentication, which is a pair of the public key for web service authentication, and a secret key for authentication module authentication used for authentication of the authentication module in a tamper resistant area.
The terminal has an authentication module authentication public key that is a pair of the authentication module authentication secret key,
Information to be processed using the authentication module authentication public key and the authentication module authentication private key is encrypted and transmitted / received between the terminal and the key store.
An authentication system characterized by The user authentication based on the release of the screen lock set in the terminal is authentication that gives the authority to use the authentication module authentication public key for accessing the key store.
The authentication system according to claim 1, characterized in that: When the web service registers a user of the terminal or when authenticating a user of the terminal trying to access the web service:
The terminal has a public key for the authentication module authentication, and the key store has a secret key for the authentication module authentication between the terminal and the key store Confirm with
When the possession of the key is not established, when the WEB service registers the user of the terminal, or when authenticating the user of the terminal attempting to access the WEB service, the terminal and the key store Execute the process of establishing the holding of the key between
The authentication system according to claim 2, characterized in that: The key store is arranged on the Internet side as a first key store, and a second key store holding a predetermined key is arranged on the local network side.
Performing a process related to an initial registration of the user of the terminal in the second key store, encrypting a process result when the process is performed in the second key store, and transmitting the encrypted result to the first key store;
The authentication system according to any one of claims 1 to 3, characterized in that: A key processing cooperation method in an authentication system in which a terminal including an authentication module for performing user authentication, a WEB service used by the terminal, and a key store having a predetermined key are communicably connected.
The web service has a public key for web service authentication used for authentication for the terminal to access the web service, and the key store is for web service authentication that is a pair of the public key for web service authentication. In the aspect of confining the secret key in the tamper resistant area,
The key store is
Generating an authentication module authentication private key and an authentication module authentication public key used for authentication of the authentication module, and transmitting the authentication module authentication public key to the terminal;
Encrypting and transmitting information processed using the authentication module authentication public key and the authentication module authentication private key between the terminal and the key store;
A key processing cooperation method characterized in that. A computer as the key store of an authentication system in which a terminal including an authentication module for performing user authentication, a web service used by the terminal, and a key store having a predetermined key are communicably connected.
The web service has a public key for web service authentication used for authentication for the terminal to access the web service, and the key store is for web service authentication that is a pair of the public key for web service authentication. In the aspect of confining the secret key in the tamper resistant area,
A means for generating an authentication module authentication secret key and an authentication module authentication public key used for authentication of the authentication module, and transmitting the authentication module authentication public key to the terminal;
Means for encrypting and transmitting information processed using the authentication module authentication public key and the authentication module authentication private key between the terminal and the key store;
Key processing collaboration program to function as.

Images