WO2019156081A1 - 端末登録システムおよび端末登録方法 - Google Patents

端末登録システムおよび端末登録方法 Download PDF

Info

Publication number
WO2019156081A1
WO2019156081A1 PCT/JP2019/004088 JP2019004088W WO2019156081A1 WO 2019156081 A1 WO2019156081 A1 WO 2019156081A1 JP 2019004088 W JP2019004088 W JP 2019004088W WO 2019156081 A1 WO2019156081 A1 WO 2019156081A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
registration
service site
fido
authenticator
Prior art date
Application number
PCT/JP2019/004088
Other languages
English (en)
French (fr)
Inventor
豪生 西村
山下　高生
康彦 吉村
聖 古川
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US16/964,806 priority Critical patent/US11483159B2/en
Publication of WO2019156081A1 publication Critical patent/WO2019156081A1/ja
Priority to US17/824,488 priority patent/US11917076B2/en
Priority to US17/824,670 priority patent/US20220286297A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Definitions

  • the present invention relates to a terminal registration system and a terminal registration method.
  • FIDO Fast IDentity Online
  • FIDO a de facto standard technique for passwordless authentication
  • FIDO a different public / private key pair is generated for each service, the public key is arranged on the service site side, and the secret key is confined in the terminal.
  • the use of the private key is based on the premise that biometric authentication is performed on the terminal, and the use of the private key is performed within the authenticator, and the private key appears outside the terminal. Security is high because there is nothing.
  • FIDO authentication In order to use the FIDO authentication, it is necessary to register the terminal with respect to the service site in advance and associate the terminal's public key with the account. In the standard technology, it is assumed that Registration is executed after logging into an account by an authentication method other than FIDO. Providing a plurality of authentication means for service providers is a heavy operational burden and can be a security hole. Therefore, after registration of the terminal at the timing of account creation, etc., it is conceivable to use only FIDO as the only authentication. Consider a use case in which different terminals are linked to an account in such an environment.
  • FIG. 9 is a diagram for explaining the characteristics of the standard technology (FIDO).
  • the terminal 1 and the terminal 2 are access controlled by biometric authentication or the like.
  • Terminal 1 and terminal 2 and service site A21 and service site B22 are authenticated by the FIDO protocol.
  • the user uses the terminal 1 to access the service site A21 and the service site B22, and uses the terminal 2 to access the service site A21 and the service site B22.
  • Service site A21 and service site B22 register individual keys for each terminal.
  • Terminal 1 and terminal 2 generate individual key pairs for each site.
  • Public keys 1-A and 2-A are registered in service site A21
  • public keys 1-B and 2-B are registered in service site B22.
  • a secret key 1-A paired with the public key 1-A and a secret key 1-B paired with the public key 1-B are stored.
  • a secret key 2-A paired with the public key 2-A and a secret key 2-B paired with the public key 2-B are stored.
  • FIG. 10 is a diagram for explaining registration of a new terminal in the standard technology (FIDO).
  • a terminal 2 in FIG. 10 is a terminal newly added separately from the terminal 1 (hereinafter referred to as a new terminal 2).
  • the new terminal 2 is generated by adding or changing a terminal (for example, having two smartphones and a tablet terminal and changing the terminal model).
  • a terminal for example, having two smartphones and a tablet terminal and changing the terminal model.
  • FIG. 10 when the new terminal 2 is used, since there is no key in the authenticator 10 of the new terminal 2, it is necessary to generate and register a key pair again for each service.
  • CTAP Client To Authenticator Protocol
  • FIDO authentication is performed using the secret key of the registered terminal (terminal 1 in FIG. 10), and after logging in, the key registration of the new terminal (terminal 2 in FIG. 10) is performed.
  • the following method 1 and method 2 can be considered.
  • FIG. 11 is a diagram for explaining the first key registration method 1 using CTAP. Note that CTAP expressed in a cylindrical shape in FIG. 11 indicates the use of CTAP, and Session expressed in a cylindrical shape indicates that the Session is established on the communication path.
  • Procedure 1 Access the registration target service site with the new terminal 2.
  • Procedure 2 The new terminal 2 uses the terminal 1 as an external authenticator (uses CTAP), and performs FIDO authentication with the registered secret key and logs in.
  • Procedure 3 A communication session is established between the service site (service site A21) and the new terminal 2.
  • Procedure 4 Registration of the authenticator key of the new terminal 2 itself via the established communication session.
  • FIG. 12 is a diagram for explaining a method 2 of key registration of a new terminal using CTAP.
  • Procedure 1 The terminal 1 accesses the registration target service site (service site A21).
  • Procedure 2 Log in by performing FIDO authentication with the registered private key in the authenticator of terminal 1 itself.
  • Procedure 3 A communication session is established between the service site and the terminal 1.
  • Procedure 4 The terminal 1 uses the new terminal 2 as an external authenticator (uses CTAP) and registers the key of the external authenticator (new terminal 2).
  • FIDO Alliance “SIMPLER, STRONGER AUTHENTICATION”, FIDO is the World ’s Largest Ecosystem for Standards-Based, Interoperable Authentication [online], [Search January 20, 2018], Internet ⁇ https://fidoalliance.org/> R. Lindemann, et al., FIDO 2.0: Client To Authenticator Protocol, FIDO Alliance Review Draft, 2016.
  • FIG. 13 is a diagram for explaining a problem in making available a number of service sites.
  • FIG. 13 shows an example of the method 1 of FIG. 11, but the same applies to the method 2 of FIG.
  • the registered terminal 1 uses a number of service sites (service site A21, service site B22, service site C23, and service site D24).
  • a secret key 1-A paired with the public key 1-A
  • a secret key 1-B paired with the public key 1-B
  • a secret key 1-D to be paired with the public key 1-D.
  • the target site for example, input a URL, via a search site
  • the conventional method has the following problems.
  • the present invention has been made in view of such a background, and it is an object of the present invention to provide a terminal registration system and a terminal registration method that improve user convenience when registering a new terminal to a plurality of service sites.
  • the invention according to claim 1 uses a registered terminal in which a plurality of terminals that perform FIDO authentication using a secret key and a service site used by the terminal are connected to be communicable.
  • a terminal registration system for registering new terminals for a plurality of the service sites, wherein the registered terminal has service site list information for associating the secret key with a URL for accessing the service site.
  • the service site list information is acquired, and based on the service site list information, the registration-target service site is FIDO-authenticated using a secret key of the registered terminal, and a new encryption is generated by the new terminal
  • a terminal registration system comprising a registration function unit for performing key registration is provided.
  • a plurality of terminals that perform FIDO authentication using a secret key and a service site used by the terminals are connected to be communicable, and a plurality of the services are registered using registered terminals.
  • a terminal registration method of a terminal registration system for registering a new terminal for a site, wherein the registered terminal has service site list information for associating the secret key with a URL for accessing the service site in an authenticator The registration function unit obtains the service site list information, performs the FIDO authentication to the service site to be registered using the secret key of the registered terminal based on the service site list information, and the new terminal And a step of performing registration of the encryption key newly generated in step 1, and a terminal registration method for executing.
  • registration is performed based on the service site list information acquired by the registration function unit. Since registration is performed by automatically accessing the target service site, it is possible to improve user convenience regarding registration to a plurality of service sites. In addition, the user does not have a burden of managing a service site to be registered at the start of use of a new terminal. Furthermore, the work burden on the user when the number of service sites increases is reduced.
  • the registration function unit is arranged on the registered terminal side, and logs in to a registration target service site for all secret keys registered in the authenticator of the registered terminal.
  • the registration result is displayed on the registered terminal side that was originally used, so that the user can confirm the registration result on the registered terminal side that has been used.
  • the registration function unit is arranged on the new terminal side, acquires service site list information from the authenticator of the registered terminal, and based on the service site list information,
  • the service site uses the registered terminal as an external authenticator by CTAP, performs login using FIDO authentication, and the new terminal performs registration related to its own authenticator on an established session. 1 as a terminal registration system.
  • the registration result is displayed on the new terminal side, so that the user can check the registration result on the new terminal side that he / she wants to use now.
  • the registration function unit is arranged in an external device different from the registered terminal and the new terminal, acquires service site list information from the authenticator of the registered terminal, Based on the site list information, for each service site, after performing login authentication using the registered terminal as an external authenticator and logging in, the new terminal is used as an external authenticator and newly registered.
  • the terminal registration system according to claim 1 is provided.
  • the registration function unit is arranged on the external device side, it is possible to achieve a functional configuration that minimizes the necessary functions on the terminal side.
  • the invention according to claim 5 is the terminal registration system according to claim 1, wherein the registration function unit notifies the user of the registration progress status to each service site.
  • the user can confirm the progress of registration to the service site (for example, the number of target sites, the number of registration completions, registration failure).
  • the site that is not valid can be confirmed by indicating the failed site.
  • the terminal registration according to the first aspect, wherein the registration function unit performs a retry control for executing a predetermined number of retries when the registration to each service site fails.
  • the present invention it is possible to provide a terminal registration system and a terminal registration method that improve user convenience when registering a new terminal in a plurality of service sites.
  • FIG. 1 It is a sequence diagram which shows retry control and a progress status notification. It is a figure explaining the characteristic of a standard technique (FIDO). It is a figure explaining registration of a new terminal in standard technology (FIDO). It is a figure explaining the method 1 of the key registration of the new terminal using CTAP. It is a figure explaining the technique 2 of the key registration of the new terminal using CTAP. It is a figure explaining the subject at the time of making it available about many service sites. It is a figure explaining the secure sharing technique of a secret key, (a) is a figure which shows the sharing technique by a centralized sharing system, (b) is a figure which shows the sharing technique by a distributed sharing system. It is a figure explaining the convenience improvement technique of re-registration.
  • FIG. 14A and 14B are diagrams for explaining a secret key secure sharing technique.
  • FIG. 14A shows a sharing technique based on a centralized sharing scheme
  • FIG. 14B shows a sharing technique based on a distributed sharing scheme.
  • a technique for securely sharing a secret key between terminals based on identification information has been proposed (see Non-Patent Document 3).
  • the terminals 1 and 2 store the authentication key in the key store 30.
  • the terminals 1 and 2 perform access control based on the personal identification information to access the key store 30 and share the same key stored in the key store 30.
  • key sharing between the registered terminal 1 and the new terminal 2 is performed.
  • the registered terminal 1 confirms the owner match with the new terminal 2 based on the identity confirmation information. If the owner match is confirmed, the registered terminal 1 uses the authentication key of the registered terminal 1 as the new terminal 2.
  • Duplicate to. With either sharing technique of the centralized sharing system or the distributed sharing system, FIDO authentication can be used without newly registering a new terminal.
  • the FIDO specification is based on the premise that the secret key is confined to the terminal. In order to use any of the above-mentioned shared technologies, a terminal that conforms to the FIDO standard specification cannot be used as it is, and a terminal that has been uniquely extended is used. Need to use.
  • FIG. 15 is a diagram for explaining a convenience improvement technique for re-registration.
  • a signature created with the secret key of the registered terminal 1 is given to the new terminal 2 in advance.
  • a technique has been proposed that enables registration of the new terminal 2 to be performed at any timing and without user work (see Non-Patent Document 4).
  • the user can automatically access all the service sites 21 at the first time of the new terminal 2 and automatically perform the registration work without first performing the registration work (without the user work). Registration is performed. For this reason, there is no user work load proportional to the number of service sites.
  • the FIDO protocol needs to be extended in order to automatically perform registration, and a function for managing signature information on the new terminal 2 is necessary.
  • the present technology cannot use a terminal conforming to the FIDO standard specification as it is, and needs to use a terminal that is uniquely expanded.
  • the present invention improves user convenience when registering a new terminal for a plurality of service sites using registered terminals.
  • FIG. 1 is a diagram showing an outline of the present invention.
  • the terminal registration system includes a service manager list (registration manager 100 (registration)) that performs service site list information 110 stored in the authenticator 10 of the registered terminal 1 and registration of the new terminal 2 to a plurality of service sites. Functional part).
  • the service site list information 110 is a URL list for managing a secret key and a URL (Uniform Resource Locator) of a target site in association with each other.
  • the service site list information 110 is stored in the authenticator 10 (authentication device) of the registered terminal 1.
  • the Registration Manager 100 controls both the registered terminal 1 and the new terminal 2 as described below.
  • the Registration Manager 100 acquires the service site list information 110 stored in the authenticator 10 of the registered terminal 1 from the registered terminal 1 (see symbol a in FIG. 1).
  • the Registration Manager 100 uses the secret key of the registered terminal 1 to perform FIDO authentication to the service site to be registered, and performs registration of the encryption key newly generated by the new terminal 2.
  • the Registration Manager 100 automatically executes the above Registration process for all sites of the URL stored in the service site list information 110. For example, the Registration Manager 100 automatically registers new terminals 2 using registered terminals 1 for all service sites (service site A21, service site B22,...) Based on the acquired service site list information 110. Execute (see symbol b in FIG. 1).
  • the Registration Manager 100 also displays a registration progress status for the user, and also performs retry control when a failure occurs due to a communication failure or the like (described later in FIG. 8).
  • the Registration Manager 100 performs the FIDO authentication to the registration target service A site using the secret key 1-A of the registered terminal 1 (see symbol c in FIG. 1).
  • the Registration Manager 100 performs Registration (registration processing) of the encryption key newly generated by the new terminal 2 (see reference numeral d in FIG. 1).
  • the above is an example of automatically executing registration of the new terminal 2 using the registered terminal 1 with respect to the service site A21, but the same processing is performed for the service site B22 (see symbols e and f in FIG. 1). .
  • the Registration Manager 100 performs the FIDO authentication to the registration target service site using the secret key of the registered terminal 1 and the registration of the encryption key newly generated by the new terminal 2 for all the service sites. It should be noted that the Registration Manager 100 may be arranged outside the registered terminal 1 side, the new terminal 2 side, the registered terminal 1 and the new terminal 2.
  • An example of arranging the Registration Manager 100 on the registered terminal 1 side is the first embodiment
  • an example of arranging the Registration Manager 100 on the new terminal 2 side is the second embodiment
  • an example of arranging the Registration Manager 100 outside the terminal is the third embodiment.
  • FIG. 2 is a block diagram showing a terminal registration system according to the first embodiment of the present invention. Note that CTAP expressed in a cylindrical shape in FIG. 2 indicates the use of CTAP, and Session expressed in a cylindrical shape indicates that the Session is established on the communication path.
  • the terminal registration system includes a service site 20 and a DNS (Domain Name System) server on a network in addition to a registered terminal (terminal 1) and a new terminal (terminal 2). 30 (see FIG. 3).
  • the registered terminal (terminal 1), the new terminal (terminal 2), the service site 20, and the DNS server 30 are connected via a communication network (not shown) and can communicate with each other.
  • the service site 20 includes a Web application server 211 and an FIDO server 212.
  • the web application server 211 is a web server having a software execution environment, a cooperation function, and the like.
  • the Web application server 211 has a function of performing complicated processing in connection with and cooperation with the FIDO server 212.
  • the Web application server 211 is a Web server operated by a service provider operating an EC (Electronic Commerce) site, for example, and performs registration and authentication of a user who uses the service.
  • EC Electronic Commerce
  • the FIDO server 212 is responsible for FIDO authentication, and only the part of the Web application server 211 that performs authentication is separated and used as a library.
  • Terminals 1 and 2 are authentication terminals such as mobile terminals such as smartphones, mobile phones, and tablets, notebook / desktop PCs, and various electronic devices.
  • a smartphone is taken as an example.
  • the terminals 1 and 2 have a normal area in which normal applications and the like operate, and an authenticator 10 that is an area that is managed so that malware and the like are not mixed (an area that is managed so that it cannot be illegally entered from the outside) ( Secure area).
  • the normal area is an environment where a general application program is executed.
  • the normal area includes a user agent 11 and a FIDO client 12.
  • the authenticator 10 exists in an area managed so as to prevent unauthorized entry from the outside, and stores biometric information (such as fingerprint information).
  • the authenticator 10 is executed in a privileged mode of a CPU (Central Processing Unit) or OS (Operating System), and can call the program of the authenticator 10 and access data only by a specific program or a specific procedure.
  • the authenticator 10 authenticates the key to perform challenge / response authentication. It also handles the key handling part, such as making the key usable after biometric authentication.
  • the authenticator 10 displays an authentication screen such as fingerprint authentication and authenticates the user. Further, the authenticator 10 signs the random number obtained from the service site 20 with a user secret key, and transmits it to the service site 20.
  • the user agent 11 is a browser or the like for the user to access the Web application server 211 of the service site 20.
  • the user agent 11 issues a key registration request and an authentication request to the Web application server 211 of the service site 20 using the Web service.
  • the FIDO client 12 is paired with the FIDO server 212 of the service site 20, transmits its own user protocol to the FIDO server 212 (FIDO library), and exchanges authentication messages with the FIDO server 212. To do.
  • the FIDO client 12 assembles a message and a protocol, whereas the authenticator 10 handles a part related to the handling of a key in the message assembly and protocol assembly performed by the FIDO client 12.
  • the FIDO server 212 that has received a request for “start user authentication” from the Web application server 211 of the service site 20 sends information such as a random number generated by itself to the FIDO client 12 via the user agent 11 of the terminals 1 and 2. Send.
  • the FIDO client 12 that has received the FIDO authentication request requests the authenticator 10 for user registration.
  • the authenticator 10 displays an authentication screen such as fingerprint authentication and authenticates the user.
  • the authenticator 10 signs the random number obtained from the web application server 211 of the service site 20 with a secret key, and transmits it to the FIDO server 212 of the service site 20.
  • the FIDO server 212 verifies the received signature (authenticates the user) and returns an authentication result to the Web application server 211.
  • the FIDO server 212 that has received a request for “start user registration” from the Web application server 211 of the service site 20 sends information such as a random number generated by itself to the FIDO client 12 via the user agent 11 of the terminals 1 and 2. Send.
  • the FIDO client 12 that has received the FIDO registration request requests the authenticator 10 for user registration.
  • the authenticator 10 displays a registration screen for biometric information such as a fingerprint and allows the user to register biometric information.
  • the authenticator 10 When the registration is completed, the authenticator 10 generates a public key encryption key pair and associates it with the user.
  • a signature is generated from the public key or a random number acquired from the server using the private key of the authenticator 10 and transmitted to the FIDO server 212 of the service site 20 via the FIDO client 12.
  • the FIDO server 212 verifies the received signature (authenticator validity check), registers the user's public key, and returns the result to the Web application server 211.
  • the registered terminal 1 pairs in the authenticator 10 with a private key 1-A paired with the public key 1-A, a private key 1-B paired with the public key 1-B, and a public key 1-C.
  • the secret key 1-C and the service site list information 110 are stored.
  • the service site list information 110 manages the private key and the URL of the target site in association with each other. For example, as shown in FIG. 2, the service site list information 110 includes a secret key “0A295BE44F ...” and a site URL “https://svcA.com”, and a secret key “129CC8B6A2 ..” and a site URL “https”.
  • the secret key and the URL of the target site may be linked, and the user name may be linked. In this way, users with a plurality of user names can use one URL, or conversely, the combination of the secret key and the URL of the target site can be changed for each user name.
  • the Registration Manager 100 is arranged on the registered terminal 1 side.
  • the Registration Manager 100 performs registration for all secret keys registered in the authenticator 10 of the registered terminal 1 after logging in to the target service site and using the new terminal 2 as an external authenticator by CTAP.
  • the Registration Manager 100 acquires service site list information 110 of registered terminal 1 from Authenticator 10.
  • the Registration Manager 100 executes the following procedures 2 to 4 for all URLs of the acquired service site list information 110.
  • Procedure 2 The Registration Manager 100 accesses the service site 20 of the registration target URL based on the acquired service site list information 110.
  • Procedure 3 The Registration Manager 100 uses the secret key registered in the internal authenticator 10 of the registered terminal 1 to perform the FIDO authentication to the target service site 20 and logs in to establish a session.
  • Procedure 4 The new terminal 2 is used as an external authenticator 10 by CTAP, and registration of a secret key is performed.
  • the Registration Manager 100 obtains the service site list information 110 to know that the registered terminal 1 has the secret key of the service site list information 110, but has no means for presenting it to the service site 20. . From the service site 20, when the Registration Manager 100 of the registered terminal 1 accesses, it is in a state where it cannot be authenticated which user it is. Therefore, in the procedure 3 described above, the Registration Manager 100 uses the private key registered in the internal authenticator 10 of the registered terminal 1 to perform the FIDO authentication to the target service site 20 and logs in to establish a session. Next, in the procedure 4, the new terminal 2 is used as the external authenticator 10 by CTAP, and the new terminal 2 is registered by performing the registration of the secret key.
  • FIG. 3 is a sequence diagram showing a terminal registration method of the terminal registration system according to the present embodiment.
  • the terminal 1 is a registered terminal, and stores the service site list information 110 in the authenticator 10.
  • a registration manager 100 is arranged in the terminal 1.
  • Terminal 2 is a new terminal.
  • the DNS server (Domain Name System) 30 has an extension (SRV (SeRVice record)) for returning the URL of the service provided on the corresponding URL in addition to the most primitive function for converting the domain name into the IP address format. Record) and use it.
  • the DNS server 30 provides the location of a service for executing re-registration provided on the site URL in the form of an SRV record.
  • the user adds and changes the new terminal 2 (for example, has two smartphones and tablet terminals and changes the terminal model).
  • the new terminal 2 for example, has two smartphones and tablet terminals and changes the terminal model.
  • the start operation of the user is transmitted to the Registration Manager 100 of the registered terminal 1 (hereinafter referred to as Registration Manager 100) (step S101), and the Registration Manager 100 uses the new terminal 2 to perform the FIDO authentication to the FIDO client 12 of the registered terminal 1.
  • a request is transmitted (step S102).
  • the FIDO client 12 of the registered terminal 1 establishes a CTAP channel with the authenticator 10 of the new terminal 2 (step S103).
  • the FIDO client 12 of the registered terminal 1 notifies the registration manager 100 of the establishment of the CTAP channel (step S104).
  • the Registration Manager 100 transmits an acquisition request for the service site list information 110 (see FIG. 2) to the authenticator 10 of the registered terminal 1 (step S105).
  • the authenticator 10 of the registered terminal 1 performs user confirmation to prevent unauthorized acquisition of an unintended list (step S106).
  • User confirmation is user authentication such as information using biometric information (fingerprint, face, iris, vein) or PIN (Personal Identification Number) code authentication.
  • the authenticator 10 of the registered terminal 1 transmits the service site list information 110 stored in the authenticator 10 to the registration manager 100 when the user confirmation is obtained by biometric authentication or the like (step S107).
  • the above is “acquisition of service site list information” of procedure 1 in FIG.
  • the subsequent sequence is a repetition for all the sites in the service site list information (corresponding to steps 2 to 4 in FIG. 2; refer to the one-dot chain line in FIG. 3).
  • the Registration Manager 100 refers to the acquired service site list information 110 (see FIG. 2) and sends a DNS query to the DNS server 30 to access the re-registration service provided on the site. An inquiry is made about a URL for registration (hereinafter referred to as a registration endpoint) (step S108).
  • the DNS server 30 transmits the registration endpoint to the Registration Manager 100, and the Registration Manager 100 acquires the registration endpoint (Step S109).
  • the Registration Manager 100 transmits the acquired registration endpoint to the user agent 11 of the registered terminal 1 (step S110).
  • the user agent 11 of the registered terminal 1 accesses the registration endpoint with respect to the Web application server 211 of the service site 20 (step S111).
  • the Web application server 211 of the service site 20 outputs an FIDO authentication request to the FIDO server 212 and starts the FIDO authentication (step S112).
  • the FIDO standard between the FIDO server 212 of the service site 20 and the authenticator 10 of the registered terminal 1 via the Web application server 211 of the service site 20, the user agent 11 of the registered terminal 1, and the FIDO client 12 is used. Perform Authentication operation.
  • the authentication operation of the FIDO standard shown in the dashed box in FIG. 3 performs the FIDO authentication to the registration target service site using the secret key stored in the internal authenticator 10 of the registered terminal 1.
  • the FIDO server 212 of the service site 20 issues an FIDO Authentication Request to the Web application server 211 (Step S113), and the Web application server 211 transmits the FIDO Authentication Request to the user agent 11 of the registered terminal 1 (Step S114). ).
  • the user agent 11 of the registered terminal 1 sends an FIDO Authentication Request to the FIDO client 12 (step S115), and the FIDO client 12 sends this FIDO Authentication Request to the authenticator 10 of the registered terminal 1 (step S116).
  • Authenticator 10 of registered terminal 1 performs user confirmation by biometric authentication using biometric information (fingerprint, face, iris, vein) (step S117).
  • biometric information fingerprint, face, iris, vein
  • step S117 biometric information
  • the biometric authentication in step S117 be as simple as possible, for example, biometric authentication using fingerprints.
  • FIDO extended function of the standard technology
  • the FIDO is a terminal that separates personal identification by biometric authentication and server authentication, and does not send a password to the service site 20, so there is no risk of personal information leaking.
  • a random number (challenge character string) is generated by the FIDO server 212 (the first stage of step S113), and the random number is signed with the private key of the authenticator 10 and returned.
  • the authenticator 10 of the registered terminal 1 signs the random number generated by the FIDO server 212 with the secret key of the authenticator 10 (step S118).
  • the authenticator 10 transmits the FIDO Authentication Response signed with the secret key to the FIDO client 12 (step S119), and the FIDO client 12 transmits the FIDO Authentication Response to the user agent 11 of the registered terminal 1 (step S120).
  • the web application server 211 of the service site 20 transmits the FIDO Authentication Response to the FIDO server 212 of the service site 20 (step S122).
  • the above steps S113 to S122 correspond to the authentication operation of the FIDO standard that logs in using the internal authenticator 10 (holding the registered key) of the registered terminal 1.
  • the FIDO server 212 of the service site 20 transmits the FIDO authentication OK to the Web application server 211 of the service site 20 (step S123), and between the Web application server 211 of the service site 20 and the user agent 11 of the registered terminal 1 A TLS Session is established (step S124).
  • the Web application server 211 notifies the FIDO server 212 of the start of FIDO registration (step S125).
  • the FIDO server 212 of the service site 20 issues an FIDO Registration Request to the web application server 211 (step S126), and the web application server 211 transmits the FIDO Registration Request to the user agent 11 of the registered terminal 1 (step S127). ).
  • the user agent 11 of the registered terminal 1 transmits a FIDO Registration Request to the FIDO client 12 of the registered terminal 1 (step S128), and the FIDO client 12 sends this FIDO Registration Request to the authenticator 10 of the new terminal 2 (step S128).
  • S129 ).
  • the authenticator 10 of the new terminal 2 performs user confirmation by biometric authentication using biometric information (fingerprint, face, iris, vein) (step S130).
  • biometric authentication performs biometric authentication by a fingerprint, for example. Further, authentication within a predetermined time may be omitted.
  • the authenticator 10 of the new terminal 2 When the user confirmation is obtained, the authenticator 10 of the new terminal 2 newly generates a FIDO Authentication (unregistered) secret key using CTAP (step S131).
  • the authenticator 10 of the new terminal 2 transmits the generated secret key to the FIDO client 12 of the registered terminal 1 (step S132).
  • the FIDO client 12 of the registered terminal 1 transmits the generated secret key to the user agent 11 of the registered terminal 1 (step S133).
  • the user agent 11 of the registered terminal 1 transmits the FIDO Authentication (unregistered) secret key as a FIDO Registration Response to the Web application server 211 of the service site 20 (step S134).
  • the Web application server 211 of the service site 20 transmits this FIDO Registration Response to the FIDO server 212 (step S135).
  • steps S126 to S135 the registration of the newly generated secret key is performed using the new terminal (terminal 2) as an external authenticator by CTAP, and corresponds to execution of the registration operation of the FIDO standard.
  • the FIDO authentication OK is transmitted to the Web application server 211 of the service site 20 (step S136).
  • the Web application server 211 transmits the registration completion of the FIDORegistration Request to the user agent 11 of the registered terminal 1 (step S137).
  • the user agent 11 notifies the Registration Manager 100 of the completion of registration of the FIDORegistration Request (step S138).
  • the Registration Manager 100 confirms that all service sites have completed the FIDO authentication to the registration target service site using the secret key of the registered terminal 1 and the registration of the key newly generated by the new terminal 2.
  • the Registration / Manager 100 issues a completion notification to the user and ends this sequence (step S139).
  • the Registration Manager 100 repeats for all the sites in the service site list information. Therefore, registration of a certain service site may not be completed due to a communication failure or the like. Further, when the registration progress status is displayed to the user, convenience for the user is improved. Retry control and registration progress display control will be described later with reference to FIG.
  • the terminal registration system is a system for registering a new terminal 2 for a plurality of service sites 20 using a registered terminal 1, and the registered terminal 1 includes a secret key and a service.
  • the authenticator 10 includes service site list information 110 that links URLs for accessing sites.
  • the Registration Manager 100 acquires the service site list information 110 from the authenticator 10 of the registered terminal 1. Then, the Registration Manager 100 performs FIDO authentication to the service site to be registered using the secret key of the registered terminal 1 based on the acquired service site list information 110, and registration of the encryption key newly generated by the new terminal 2 I do.
  • the Registration Manager 100 is arranged on the registered terminal 1 side.
  • the Registration Manager 100 logs in to the registration target service site for all secret keys registered in the authenticator 10 of the registered terminal 1 and uses the new terminal 2 as the external authenticator 10 by CTAP to perform registration.
  • the Registration Manager 100 automatically accesses the registration target service site based on the service site list information 110 acquired from the authenticator 10 of the registered terminal 1 and performs registration. User convenience regarding Registration can be improved.
  • the registration manager 100 acquires a list of service sites stored in the registered terminal 1 and starts registration for all of them, so that the user himself / herself uses it (the user wants to register when starting to use a new terminal). There is no burden of managing.
  • the Registration Manager 100 since the Registration Manager 100 is arranged on the registered terminal 1 side, the registration result is displayed on the registered terminal 1 that was originally used.
  • the registered terminal 1 is a terminal that can be used by the user. The user can check the registration result on the registered terminal 1 that has been used.
  • FIG. 4 is a block diagram showing a terminal registration system according to the second embodiment of the present invention.
  • CTAP expressed in a cylindrical shape in FIG. 4 indicates the use of CTAP
  • Session expressed in a cylindrical shape indicates that the Session is established on the communication path.
  • the terminal 1 is a registered terminal 1 and the terminal 2 is a new terminal 2.
  • the registered terminal 1 pairs in the authenticator 10 with a private key 1-A paired with the public key 1-A, a private key 1-B paired with the public key 1-B, and a public key 1-C.
  • the secret key 1-C and the service site list information 110 are stored.
  • the Registration Manager 100 is arranged on the new terminal 2 side.
  • the Registration Manager 100 acquires service site list information 110 of all sites from the authenticator 10 of the registered terminal 1, and uses each registered terminal 1 as the external authenticator 10 by CTAP and logs in after performing FIDO authentication.
  • the new terminal 2 executes a registration process related to its own authenticator on the established session.
  • Procedure 1 Registration Manager 100 obtains service site list information 110 of registered terminal 1 from authenticator 10 of registered terminal 1.
  • the Registration Manager 100 executes the following procedures 2 to 4 for all URLs of the acquired service site list information 110.
  • Procedure 2 The Registration Manager 100 accesses the service site 20 of the registration target URL based on the acquired service site list information 110.
  • Procedure 3 The Registration Manager 100 uses the registered terminal 1 as an external authenticator 10 by CTAP, performs FIDO authentication, logs in, and establishes a session.
  • Procedure 4 The new terminal 2 executes a Registration process related to its own authenticator on the established session.
  • FIG. 5 is a sequence diagram showing a terminal registration method of the terminal registration system according to the present embodiment.
  • the terminal 1 is a registered terminal, and the service site list information 110 is stored in the authenticator 10.
  • the terminal 2 is a new terminal, and the Registration Manager 100 is arranged.
  • the user start operation is transmitted to the Registration Manager 100 (hereinafter referred to as Registration Manager 100) of the new terminal 2 (step S201), and the Registration Manager 100 requests the FIDO client 12 of the new terminal 2 to perform the FIDO authentication with the new terminal 2. Transmit (step S202).
  • the FIDO client 12 of the new terminal 2 establishes a CTAP channel with the registered terminal 1 authenticator 10 (step S203).
  • the FIDO client 12 of the new terminal 2 notifies the registration manager 100 of the establishment of the CTAP channel (step S204).
  • the Registration Manager 100 transmits an acquisition request for the service site list information 110 (see FIG. 4) to the authenticator 10 of the registered terminal 1 (step S205).
  • the authenticator 10 of the registered terminal 1 performs user confirmation to prevent unauthorized acquisition of an unintended list (step S206).
  • User confirmation is user authentication such as biometric information (fingerprint, iris, vein) or information using a PIN.
  • the authenticator 10 of the registered terminal 1 transmits the service site list information 110 stored in the authenticator 10 to the registration manager 100 (step S207).
  • the above is “acquisition of service site list information” of procedure 1 in FIG.
  • the subsequent sequence is a repetition for all the sites in the service site list information (corresponding to steps 2 to 4 in FIG. 4; see the dashed-dotted line in FIG. 5).
  • the Registration Manager 100 refers to the acquired service site list information 110 (see FIG. 4) and sends a DNS query to the DNS server 30 to inquire about a registration endpoint (step S208).
  • the DNS server 30 transmits the registration endpoint to the Registration Manager 100, and the Registration Manager 100 acquires the registration endpoint (Step S209).
  • the Registration Manager 100 transmits the obtained registration endpoint to the user agent 11 of the new terminal 2 (Step S210).
  • the user agent 11 of the new terminal 2 accesses the registration endpoint with respect to the Web application server 211 of the service site 20 (step S211).
  • the Web application server 211 of the service site 20 outputs an FIDO authentication request to the FIDO server 212 and starts the FIDO authentication (step S212).
  • the standard of the FIDO is passed through the Web application server 211 of the service site 20, the user agent 11 of the new terminal 2, and the FIDO client 12. Perform Authentication operation.
  • the authentication operation of the FIDO standard shown in the dashed box in FIG. 5 acquires the URL list of all sites from the external authenticator 10 of the registered terminal 1, and uses the registered terminal 1 as an external authenticator by CTAP for each site, and performs the FIDO authentication. Go and log in.
  • the FIDO server 212 of the service site 20 issues an FIDO Authentication Request to the Web application server 211 (Step S213), and the Web application server 211 transmits the FIDO Authentication Request to the user agent 11 of the new terminal 2 (Step S214). .
  • the user agent 11 of the new terminal 2 transmits an FIDO Authentication Request to the FIDO client 12 of the new terminal 2 (step S215), and the FIDO client 12 sends this FIDO Authentication Request to the authenticator 10 of the registered terminal 1 (step S216). ).
  • the authenticator 10 of the registered terminal 1 performs user confirmation by biometric authentication using biometric information (fingerprint, face, iris, vein) (step S217).
  • biometric authentication performs biometric authentication by a fingerprint, for example. Further, authentication within a predetermined time may be omitted.
  • the authenticator 10 of the registered terminal 1 signs the random number generated by the FIDO server 212 with the secret key of the authenticator 10 (step S218).
  • the authenticator 10 transmits the FIDO Authentication Response signed with the private key to the FIDO client 12 (step S119), and the FIDO client 12 transmits this FIDO Authentication Response to the user agent 11 of the new terminal 2 (step S220).
  • the user agent 11 transmits the FIDO Authentication Response to the Web application server 211 of the service site 20 (step S221).
  • the web application server 211 of the service site 20 transmits the FIDO Authentication Response to the FIDO server 212 of the service site 20 (step S222).
  • the steps S213 to S222 correspond to the authentication operation of the FIDO standard in which the registered terminal 1 is used as an external authenticator by CTAP, and the login is performed by performing the FIDO authentication.
  • the FIDO server 212 of the service site 20 transmits the FIDO authentication OK to the Web application server 211 of the service site 20 (step S223), and TLS is transmitted between the Web application server 211 of the service site 20 and the user agent 11 of the new terminal 2.
  • a session is established (step S224).
  • the Web application server 211 notifies the FIDO server 212 of the start of FIDO registration (step S225).
  • the new terminal 2 executes the Registration process related to its own authenticator on the established session.
  • the FIDO server 212 of the service site 20 issues an FIDO Registration Request to the web application server 211 (step S126), and the web application server 211 transmits the FIDO Registration Request to the user agent 11 of the new terminal 2 (step S227). .
  • the user agent 11 of the new terminal 2 sends an FIDO Registration Request to the FIDO client 12 (step S228), and the FIDO client 12 sends this FIDO Registration Request to the authenticator 10 of the new terminal 2 (step S229).
  • the authenticator 10 of the new terminal 2 performs user confirmation by biometric authentication using biometric information (fingerprint, face, iris, vein) (step S230).
  • biometric authentication performs biometric authentication by a fingerprint, for example. Further, authentication within a predetermined time may be omitted.
  • the authenticator 10 of the new terminal 2 When the user confirmation is obtained, the authenticator 10 of the new terminal 2 newly generates a FIDO Authentication (unregistered) secret key using CTAP (step S231).
  • the authenticator 10 of the new terminal 2 transmits the generated secret key to the FIDO client 12 of the new terminal 2 (step S232).
  • the FIDO client 12 of the new terminal 2 transmits the generated secret key to the user agent 11 of the new terminal 2 (Step S233).
  • the user agent 11 of the new terminal 2 transmits the FIDO Authentication (unregistered) private key as a FIDO Registration Response to the Web application server 211 of the service site 20 (step S234).
  • the Web application server 211 of the service site 20 transmits this FIDO Registration Response to the FIDO server 212 (step S235).
  • the new terminal 2 corresponds to executing the registration operation of the FIDO standard in which the registration process related to its authenticator is executed on the established session.
  • the FIDO authentication OK is transmitted to the Web application server 211 of the service site 20 (step S236).
  • the Web application server 211 transmits the registration completion of the FIDORegistration Request to the user agent 11 of the new terminal 2 (step S237).
  • the user agent 11 notifies the Registration Manager 100 of the completion of registration of the FIDORegistration Request (step S238).
  • the Registration Manager 100 confirms that the registration of the key newly generated in the new terminal 2 is completed for all service sites.
  • the Registration / Manager 100 issues a completion notification to the user and ends this sequence (step S239).
  • the Registration Manager 100 repeats all the sites in the service site list information. Therefore, registration of a certain service site may not be completed due to a communication failure or the like. Retry control and registration progress display control will be described later with reference to FIG.
  • the Registration Manager 100 is arranged on the new terminal 2 side.
  • the Registration Manager 100 obtains the URL list of all service sites from the authenticator 10 of the registered terminal 1, uses the registered terminal 1 as an external authenticator 10 by CTAP for each service site, logs in by performing FIDO authentication, and the new terminal 2 On the established session, registration related to its own authenticator 10 is performed.
  • the Registration Manager 100 performs the registration by automatically accessing the URL list acquired from the authenticator 10 of the registered terminal 1. It is possible to improve user convenience related to Registration to a plurality of service sites.
  • the Registration Manager 100 since the Registration Manager 100 is arranged on the new terminal 2 side, the registration result is displayed on the new terminal 2. The user can check the registration result on the new terminal 2 side that he / she wants to use now.
  • the new terminal 2 since the new terminal 2 is often more sophisticated than the terminal that has been used so far, registration and registration with the resources of the higher-functional new terminal 2 (for example, high resolution, large screen, high speed drawing, high speed communication, etc.) Registration result can be displayed.
  • FIG. 6 is a block diagram showing a terminal registration system according to the third embodiment of the present invention.
  • CTAP expressed in a cylindrical shape in FIG. 6 indicates the use of CTAP
  • Session expressed in a cylindrical shape indicates that the Session is established on the communication path.
  • the terminal 1 is a registered terminal 1 and the terminal 2 is a new terminal 2.
  • the registered terminal 1 pairs in the authenticator 10 with a private key 1-A paired with the public key 1-A, a private key 1-B paired with the public key 1-B, and a public key 1-C.
  • the secret key 1-C and the service site list information 110 are stored.
  • the external device 3 is, for example, a PC (personal computer).
  • the external device 3 may be a USB token that is inserted into a USB (Universal Serial Bus) port of a PC.
  • the USB token is a key for using the PC, and if the USB token is not present or valid, specific data cannot be opened or connected to the network. Further, the USB token may be provided with biometric authentication means such as fingerprint authentication.
  • the external device 3 includes a user agent 11 and an FIDO client 12 in the normal area, and an authenticator 10 in the secure area.
  • the authenticator 10 of the external device 3 corresponds to the external authenticator when viewed from the terminals 1 and 2 that execute the authentication operation of the FIDO standard.
  • the Registration Manager 100 is arranged on the external device 3 side different from the registered terminal 1 and the new terminal 2.
  • the Registration Manager 100 obtains a list of URLs of all service sites from the registered terminal 1, performs login authentication for each site using the registered terminal 1 as an external authenticator, and then uses the new terminal 2 as an external authenticator. New registration.
  • the Registration Manager 100 is disposed on the external device 3 side.
  • Procedure 1 Registration Manager 100 obtains service site list information 110 of registered terminal 1 from authenticator 10 of registered terminal 1.
  • the Registration Manager 100 executes the following procedures 2 to 4 for all URLs of the acquired service site list information 110.
  • Procedure 2 The Registration Manager 100 accesses the service site 20 of the registration target URL based on the acquired service site list information 110.
  • Procedure 3 The Registration Manager 100 uses the registered terminal 1 as an external authenticator 10 by CTAP, performs FIDO authentication, logs in, and establishes a session.
  • Procedure 4 After logging in, use the new terminal 2 as an external authenticator and newly execute a registration process.
  • FIG. 7 is a sequence diagram showing a terminal registration method of the terminal registration system according to the present embodiment.
  • the user's start operation is transmitted to the Registration Manager 100 (hereinafter referred to as Registration Manager 100) of the external device 3 (Step S301), and the Registration Manager 100 authenticates the FIDO client 12 of the external device 3 with the new terminal 2.
  • a request for transmission is transmitted (step S302).
  • the FIDO client 12 of the external device 3 establishes a CTAP channel with the authenticator 10 of the registered terminal 1 (step S303).
  • the FIDO client 12 of the external device 3 establishes a CTAP channel with the authenticator 10 of the new terminal 2 (step S304). That is, the external device 3 establishes a CTAP channel between both the authenticator 10 of the registered terminal 1 and the authenticator 10 of the new terminal 2.
  • the FIDO client 12 of the external device 3 notifies the registration manager 100 of the establishment of the CTAP channel (step S305).
  • the Registration Manager 100 transmits an acquisition request for the service site list information 110 (see FIG. 7) to the authenticator 10 of the registered terminal 1 (step S306).
  • the authenticator 10 of the registered terminal 1 performs user confirmation to prevent unauthorized acquisition of an unintended list (step S307).
  • the user confirmation is user authentication such as biometric information (fingerprint, face, iris, vein) or information using a PIN.
  • the authenticator 10 of the registered terminal 1 transmits the service site list information 110 stored in the authenticator 10 to the registration manager 100 (step S308).
  • acquisition of service site list information of procedure 1 in FIG.
  • the subsequent sequence is a repetition for all the sites in the service site list information (corresponding to steps 2 to 4 in FIG. 6; see the dashed-dotted line in FIG. 7).
  • the Registration Manager 100 refers to the acquired service site list information 110 (see FIG. 6) and sends a DNS query to the DNS server 30 to inquire about a registration endpoint (step S309).
  • the DNS server 30 transmits the registration endpoint to the Registration Manager 100, and the Registration Manager 100 acquires the registration endpoint (Step S310).
  • the Registration Manager 100 transmits the acquired registration endpoint to the user agent 11 of the external device 3 (step S311).
  • the user agent 11 of the external device 3 accesses the registration endpoint with respect to the Web application server 211 of the service site 20 (step S312).
  • the Web application server 211 of the service site 20 outputs an FIDO authentication request to the FIDO server 212 of the service site 20 and starts the FIDO authentication (step S313).
  • the FIDO standard is passed through the Web application server 211 of the service site 20, the user agent 11 of the external device 3, and the FIDO client 12. Perform Authentication operation.
  • the authentication operation of the FIDO standard shown in the dashed box in FIG. 7 acquires the service site list information 110 of all service sites from the registered terminal 1, and performs the FIDO authentication for each site using the registered terminal 1 as an external authenticator. After logging in, the new terminal 2 is used as an external authenticator to newly register.
  • the FIDO server 212 of the service site 20 issues an FIDO Authentication Request to the Web application server 211 (Step S314), and the Web application server 211 transmits this FIDO Authentication Request to the user agent 11 of the external device 3 (Step S315). .
  • the user agent 11 of the external device 3 transmits an FIDO Authentication Request to the FIDO client 12 of the external device 3 (step S316), and the FIDO client 12 transmits this FIDO Authentication Request to the authenticator 10 of the registered terminal 1 (step S317). ).
  • the authenticator 10 of the registered terminal 1 performs user confirmation by biometric authentication using biometric information (fingerprint, iris, vein) (step S318).
  • biometric authentication performs biometric authentication by a fingerprint, for example. Further, authentication within a predetermined time may be omitted.
  • the authenticator 10 of the registered terminal 1 signs the random number generated by the FIDO server 212 with the secret key of the authenticator 10 (step S118).
  • the authenticator 10 transmits the FIDO Authentication Response signed with the private key to the FIDO client 12 (step S320), and the FIDO client 12 transmits this FIDO Authentication Response to the user agent 11 of the external device 3 (step S321).
  • the user agent 11 transmits the FIDO Authentication Response to the Web application server 211 of the service site 20 (step S322).
  • the web application server 211 of the service site 20 transmits the FIDO Authentication Response to the FIDO server 212 of the service site 20 (step S323).
  • steps S314 to S323 correspond to the authentication operation of the FIDO standard in which the registered terminal 1 is used as an external authenticator to perform FIDO authentication and log in.
  • the FIDO server 212 of the service site 20 transmits the FIDO authentication OK to the Web application server 211 of the service site 20 (step S324), and TLS is transmitted between the Web application server 211 of the service site 20 and the user agent 11 of the external device 3.
  • a session is established (step S325).
  • the Web application server 211 notifies the FIDO server 212 of the start of FIDO registration (step S326).
  • the registration operation of the FIDO standard shown in a broken line in FIG. 7 is to perform registration processing by using the new terminal 2 as an external authenticator after performing login authentication using the registered terminal 1 as an external authenticator and logging in. It is.
  • the FIDO server 212 of the service site 20 issues an FIDO Registration Request to the Web application server 211 (Step S327), and the Web application server 211 transmits the FIDO Registration Request to the user agent 11 of the external device 3 (Step S328). .
  • the user agent 11 of the external device 3 transmits an FIDO Registration Request to the FIDO client 12 (step S329), and the FIDO client 12 sends this FIDO Registration Request to the authenticator 10 of the new terminal 2 (step S330).
  • the authenticator 10 of the new terminal 2 performs user confirmation by biometric authentication using biometric information (fingerprint, iris, vein) (step S331).
  • biometric authentication performs biometric authentication by a fingerprint, for example. Further, authentication within a predetermined time may be omitted.
  • the authenticator 10 of the new terminal 2 When the user confirmation is obtained, the authenticator 10 of the new terminal 2 newly generates a FIDOAuthentication (unregistered) secret key using CTAP (step S332).
  • the authenticator 10 of the new terminal 2 transmits the generated secret key to the FIDO client 12 of the external device 3 (step S333).
  • the FIDO client 12 of the external device 3 transmits the generated secret key to the user agent 11 of the external device 3 (step S334).
  • the user agent 11 of the external device 3 transmits the FIDO Authentication (unregistered) secret key as a FIDO Registration Response to the Web application server 211 of the service site 20 (step S335).
  • the Web application server 211 of the service site 20 transmits this FIDO Registration Response to the FIDO server 212 of the service site 20 (step S336).
  • the new terminal 2 is used as an external authenticator, and the registration operation of the FIDO standard that newly executes the registration process corresponds to the execution.
  • the FIDO authentication OK is transmitted to the Web application server 211 of the service site 20 (step S337).
  • the Web application server 211 transmits registration completion of the FIDO Registration Request to the user agent 11 of the external device 3 (step S338).
  • the user agent 11 notifies the registration manager 100 of the completion of registration of the FIDORegistration request (step S339).
  • the Registration Manager 100 confirms that the registration of the key newly generated in the new terminal 2 is completed for all service sites.
  • the Registration / Manager 100 issues a completion notification to the user and ends this sequence (step S340).
  • the Registration Manager 100 repeats all the sites in the service site list information. Therefore, registration of a certain service site may not be completed due to a communication failure or the like. Retry control and registration progress display control will be described later with reference to FIG.
  • the Registration Manager 100 is arranged on the external device 3 side different from the registered terminal 1 and the new terminal 2.
  • the Registration Manager 100 obtains a URL list of all service sites from the registered terminal 1, logs in using the registered terminal 1 as an external authenticator 10 for each service site, logs in, and then sets the new terminal 2 as the external authenticator 10. Use and perform a new Registration.
  • this embodiment it is possible to improve the same effect as in the first embodiment and the second embodiment, that is, the user convenience related to Registration to a plurality of service sites.
  • the work burden on the user when the number of service sites increases is reduced.
  • the Registration Manager 100 is arranged on the external device 3 side, it is possible to have a functional configuration that minimizes necessary functions on the terminal side. You can keep your terminal resources. Further, when there is a restriction on the function of the terminal, it is possible to select on the side of the external device 3 having higher functionality.
  • FIG. 8 is a sequence diagram showing retry control / progress status notification.
  • the Registration Manager 100 may be arranged on the registered terminal 1 side, the new terminal 2 side, or outside the terminals 1 and 2.
  • the service sites 20 to be registered are assumed to be a service site A21, a service site B22, and a service site C23.
  • the user start operation is transmitted to the Registration Manager 100 (Step S401), and the Registration Manager 100 acquires the service site list information 110 from the registered terminal 1 (Step S402). Then, the Registration Manager 100 notifies the user of registration start (step S403).
  • a specific sequence from the user start operation to acquisition of the service site list information 110 has been described in detail with reference to FIGS. 3, 5, and 7.
  • the terminal is informed to the user that “registration start” and the number of registration target sites are “3” as the progress status.
  • This notification is displayed, for example, in the notification column of the corresponding application on the display screen of the terminal. In this example, “registration start” and “target: 3 completion: 0 failure: 0” are displayed.
  • the Registration Manager 100 performs registration for each service site by using the registered terminal 1 or the new terminal 2 as an external authenticator by CTAP. That is, the Registration Manager 100 outputs an FIDO authentication start request for registration to the service site A21 to start FIDO authentication (step S404), and executes an authentication operation of the FIDO standard with the registered terminal 1 ( Step S405). The Registration Manager 100 receives the FIDO authentication result from the service site A21 (step S406).
  • the Registration Manager 100 outputs an FIDO authentication registration request to the service site A21 to start FIDO authentication registration (step S407), and executes an FIDO standard Registration operation with the new terminal 2 (step S408).
  • the Registration Manager 100 receives the FIDO authentication registration result from the service site A21 (step S409).
  • the authentication operation of the FIDO standard and the registration operation of the FIDO standard have been described in detail with reference to FIG. 3, FIG. 5, and FIG.
  • Step S410 the Registration Manager 100 notifies the user of the registration progress update (Step S410). As shown by a symbol h in FIG. 8, “registration progress” “target: 3 completion: 1 failure: 0” is displayed on the terminal as the progress status.
  • the Registration Manager 100 outputs an FIDO authentication start request for registration to the service site B22 and starts FIDO authentication (step S411).
  • the FIDO authentication start request issued by the Registration Manager 100 has not reached the service site B22 (see the symbols i and x in FIG. 8). It is assumed that the FIDO authentication start request has not reached the service site B22 due to a communication failure or the like.
  • the Registration Manager 100 executes a first retry after a predetermined time. The Registration Manager 100 again transmits an FIDO authentication start request to the service site B22 (step S412).
  • the Registration Manager 100 receives the FIDO authentication result from the service site B22 (step S414).
  • the Registration Manager 100 outputs an FIDO authentication registration request to the service site B22 to start the FIDO authentication registration (step S415), and executes the FIDO standard Registration operation with the new terminal 2 (step S416).
  • Registration Manager 100 receives the FIDO authentication registration result from service site B22 (step S417).
  • the Registration Manager 100 When the registration to the service site B22 is completed, the Registration Manager 100 notifies the user of the registration progress status update (step S418). As indicated by a symbol k in FIG. 8, “registration progress” “target: 3 completion: 2 failure: 0” is displayed on the terminal as the progress status.
  • the Registration Manager 100 outputs an FIDO authentication start request for registration to the service site C23, and starts FIDO authentication (step S419).
  • the FIDO authentication start request issued by the Registration Manager 100 has not arrived at the service site C23 (see reference numerals l and x in FIG. 8).
  • the FIDO authentication start request has not reached the service site C23 due to a communication failure or the like.
  • the Registration Manager 100 executes the first retry after a predetermined time.
  • the Registration Manager 100 transmits an FIDO authentication start request to the service site C23 in the first retry (step S420).
  • the FIDO authentication start request to the service site C23 by the first retry has not arrived at the service site C23 (see symbols n and x in FIG. 8).
  • the Registration Manager 100 executes a second retry after a predetermined time when there is no response from the service site C23.
  • the Registration Manager 100 transmits a FIDO authentication start request to the service site C23 in the second retry (step S421).
  • the Registration Manager 100 determines that the registration to the service site C23 has failed after a certain number of retries (here, twice), and ends the registration process to the service site C23.
  • the Registration Manager 100 notifies the end of registration (registration failure) to the service site C23 (step S422).
  • “registration completed” “target: 3 completed: 2 failed: 1” is displayed on the terminal as the progress status. In this case, as indicated by the symbol s in FIG. 8, it is better to clearly indicate the service site that has failed to be registered. For example, the URL of the service site C23 whose registration has failed is displayed.
  • the Registration Manager 100 notifies the user of the registration progress status to each service site, so that the user confirms the registration progress status (number of target sites, registration completion count, registration failure) to the service site. can do.
  • the site that is not valid can be confirmed by indicating the failed site.
  • the Registration Manager 100 is connected by retrying when registration to a certain service site fails due to a communication failure or the like by performing retry control to perform a predetermined number of retries when registration to each service site fails. Can increase the possibility of Also, by providing the number of retries, it is possible to reduce the access time when the connection possibility is low (no).
  • each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part of the distribution / integration is functionally or physically distributed in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • each of the above-described configurations, functions, and the like may be realized by software for interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files that realize each function is stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), an IC (Integrated Circuit) card, an SD (Secure Digital) card, an optical disk, etc. It can be held on a recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供する。 【解決手段】登録済み端末１は、秘密鍵とサービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報１１０をAuthenticator１０が備える。Registration Manager１００は、登録済み端末１のAuthenticator１０からサービスサイト一覧情報１１０を取得する。そして、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。

Description

端末登録システムおよび端末登録方法
　本発明は、端末登録システムおよび端末登録方法に関する。
　パスワード認証に替わる利用者認証技術として、パスワードレス認証のデファクト標準技術（ＦＩＤＯ：Fast IDentity Online）という、公開鍵暗号を用いたＷｅｂサービスの利用者認証技術がある（非特許文献１参照）。
　ＦＩＤＯでは、サービス毎に異なる公開鍵・秘密鍵ペアを生成し、公開鍵をサービスサイト側に配置して、秘密鍵を端末内に閉じ込める。秘密鍵の利用（チャレンジ・レスポンス認証における署名）は端末上で生体認証を行うことが前提となっており、かつ、秘密鍵の利用はAuthenticator内で行われ、端末外に秘密鍵が出ていくことはないことからセキュリティが高い。
　ＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。標準技術においてRegistrationは、ＦＩＤＯ以外の認証方法でアカウントにログインした上で実行することが想定されている。
　サービス事業者にとって複数の認証手段を用意するのは運用負担が大きく、セキュリティホールにもなり得る。そのため、アカウント作成のタイミング等に端末のRegistrationを行った後には、ＦＩＤＯのみを唯一の認証とすることが考えられる。このような環境で、アカウントに異なる別の端末を紐付けるユースケースを考える。
　図９は、標準技術（ＦＩＤＯ）の特徴を説明する図である。
　図９に示すように、端末１および端末２は、生体認証等でアクセス制御される。端末１および端末２と、サービスサイトＡ２１およびサービスサイトＢ２２とは、ＦＩＤＯプロトコルで認証される。利用者は端末１を使ってサービスサイトＡ２１とサービスサイトＢ２２にアクセスし、端末２を使ってサービスサイトＡ２１とサービスサイトＢ２２にアクセスしている。
　サービスサイトＡ２１およびサービスサイトＢ２２は、端末毎に個別の鍵を登録する。また、端末１および端末２は、サイト毎に個別の鍵ペアを生成する。
　サービスサイトＡ２１には公開鍵１－Ａと２－Ａが、サービスサイトＢ２２には公開鍵１－Ｂと２－Ｂとが登録済みである。
　端末１のAuthenticator１０（セキュア領域）には、公開鍵１－Ａとペアになる秘密鍵１－Ａと、公開鍵１－Ｂとペアになる秘密鍵１－Ｂとが格納されている。
　端末２のAuthenticator１０（セキュア領域）には、公開鍵２－Ａとペアになる秘密鍵２－Ａと、公開鍵２－Ｂとペアになる秘密鍵２－Ｂとが格納されている。
　図１０は、標準技術（ＦＩＤＯ）において、新規端末の登録を説明する図である。図１０における端末２は、端末１とは別に新しく追加される端末（以下、新規端末２という）である。新規端末２は、端末の追加、変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）によって生じる。新規端末２でＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。
　図１０に示すように、新規端末２を利用する場合、新規端末２のAuthenticator１０内には鍵がないことから、サービス毎に再度鍵ペアの生成・登録を行う必要がある。
　端末外部のAuthenticatorを利用してＦＩＤＯ認証を行うためのプロトコルとしてＣＴＡＰ（Client To Authenticator Protocol）が規定されている（非特許文献２参照）。
　ＣＴＡＰを利用することで、登録済み端末（図１０の端末１）の秘密鍵を用いてＦＩＤＯ認証を行い、ログインした上で、新規端末（図１０の端末２）の鍵のRegistrationを行う方法として、以下の手法１と手法２が考えられる。
　図１１は、ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法１を説明する図である。なお、図１１の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。
　手順１：新規端末２で登録対象のサービスサイトにアクセスする。
　手順２：新規端末２は、端末１を外部Authenticatorとして利用する（ＣＴＡＰを用いる）ことで、登録済みの秘密鍵によってＦＩＤＯ認証を行ってログインする。
　手順３：サービスサイト（サービスサイトＡ２１）と新規端末２間で通信セッションが確立する。
　手順４：確立した通信セッション経由で新規端末２自身のAuthenticatorの鍵をRegistrationする。
　図１２は、ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法２を説明する図である。
　手順１：端末１で登録対象のサービスサイト（サービスサイトＡ２１）にアクセスする。
　手順２：端末1自身のAuthenticator内の登録済みの秘密鍵によってＦＩＤＯ認証を行ってログインする。
　手順３：サービスサイトと端末1間で通信セッションが確立
　手順４：端末１は、新規端末２を外部Authenticatorとして利用（ＣＴＡＰを用いる）し、外部Authenticator（新規端末２）の鍵をRegistrationする。
FIDO Alliance,"SIMPLER, STRONGER AUTHENTICATION", FIDO is the World’s Largest Ecosystem for Standards-Based, Interoperable Authentication ［online］,［平成３０年１月２０日検索］,インターネット  〈 https://fidoalliance.org/〉 R. Lindemann, et al., FIDO 2.0: Client To Authenticator Protocol, FIDO Alliance Review Draft, 2016.［平成３０年１月２０日検索］,インターネット  〈 URL :https://fidoalliance.org/specs/fido-v2.0-rd-20161004/fido-client-to-authenticator-protocol-v2.0-rd-20161004.html〉 西村ら, "同一所有者に属する端末間のユーザ認証用秘密鍵のセキュアな共有に関する一検討", 電子情報通信学会 技術研究報告, IN2016-172, pp.449-454, 2017. A. Takakuwa, et al., "The Transfer Access Protocol - Moving to New Authenticators in the FIDO Ecosystem", Technical Report UW-CSE-17-06-01, The University of Washington, 2017.
　従来技術であるＣＴＡＰを用いた手法では、新規端末（図１１および図１２の新規端末２）を登録する対象のサービスサイトに個々にアクセスし、登録処理を開始することが前提となる。
　登録済み端末（図１１および図１２の端末１）で多数のサービスサイトを利用している場合、端末２を新規に導入したタイミングで、それら全てのサービスサイトについて利用可能な状態にすることが求められる。
　図１３は、多数のサービスサイトについて利用可能な状態にする際の課題を説明する図である。図１３は、図１１の手法１の例を示したが、図１２の手法２についても同様である。
　図１３に示すように、登録済み端末１は、多数のサービスサイト（サービスサイトＡ２１、サービスサイトＢ２２、サービスサイトＣ２３、およびサービスサイトＤ２４）を利用している。端末１のAuthenticator１０（セキュア領域）には、公開鍵１－Ａとペアになる秘密鍵１－Ａと、公開鍵１－Ｂとペアになる秘密鍵１－Ｂと、公開鍵１－Ｃとペアになる秘密鍵１－Ｃと、公開鍵１－Ｄとペアになる秘密鍵１－Ｄと、が格納されている。
　端末２を新規に導入したタイミングで、それら全てのサービスサイトを使えるようにしたい要請がある。このため、ユーザが対象サイトへ個々にアクセス（例えばＵＲＬ入力、検索サイト経由）してRegistrationを開始する。しかしながら、従来手法には下記のような問題がある。
（１）ユーザが個々のサービスサイトに能動的にアクセス（ＵＲＬ入力、検索エンジン経由でのページ遷移等）し、Registrationを行う必要がある。このため、サービスサイトの数に応じて作業負担が増すという課題がある。
（２）登録済み端末１で利用中の全サービスサイトについて漏れなく新規端末２のRegistrationを行う必要がある。このため、ユーザが利用中のサービスサイト全てを把握しておく負担があるという課題がある。
　このような背景を鑑みて本発明がなされたのであり、本発明は、複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供することを課題とする。
　前記した課題を解決するため、請求項１に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、前記登録済み端末は、前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorが備え、前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、前記新規端末で新規に生成した暗号鍵のRegistrationを行う登録機能部を備えることを特徴とする端末登録システムとした。
　また、請求項７に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、前記登録済み端末は、前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorに有し、登録機能部は、前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証するステップと、前記新規端末で新規に生成した暗号鍵のRegistrationを行うステップと、を実行する端末登録方法とした。
　このようにすることで、ＦＩＤＯ認証を行うサービスサイトにおいて、登録済み端末を用いて新規端末をRegistrationするユースケースを対象とする場合、登録機能部が取得したサービスサイト一覧情報をもとに、登録対象のサービスサイトに対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。また、ユーザは新規端末の利用開始時にRegistrationをしたいサービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。
　請求項２に記載の発明は、前記登録機能部が、前記登録済み端末側に配置され、前記登録済み端末の前記Authenticatorに登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、前記新規端末をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行うことを特徴とする請求項１に記載の端末登録システムとした。
　このようにすることで、元々使っていた登録済み端末側に登録結果が表示されるので、ユーザは使いなれた登録済み端末側で登録結果を確認することができる。
　請求項３に記載の発明は、前記登録機能部が、前記新規端末側に配置され、前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインし、前記新規端末は、確立されたセッション上で、自身のAuthenticatorに関するRegistrationを行うことを特徴とする請求項１に記載の端末登録システムとした。
　このようにすることで、新規端末側に登録結果が表示されるので、ユーザはいまから使いたい新規端末側で登録結果を確認することができる。
　請求項４に記載の発明は、前記登録機能部が、前記登録済み端末および前記新規端末とは異なる外部装置に配置され、前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、前記新規端末を外部Authenticatorとして用い、新規にRegistrationを行うことを特徴とする請求項１に記載の端末登録システムとした。
　このようにすることで、外部装置側に登録機能部が配置されるので、端末側の必要機能を最低限にした機能構成とすることができる。
　請求項５に記載の発明は、前記登録機能部が、ユーザに対して、各サービスサイトへの登録進捗状況を通知することを特徴とする請求項１に記載の端末登録システムとした。
　このようにすることで、ユーザはサービスサイトへの登録進捗状況（例えば対象サイト数、登録完了数、登録失敗）を確認することができる。また、失敗したサイトを明示することで、有効でないサイトを確認することができる。
　請求項６に記載の発明は、前記登録機能部が、各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行うことを特徴とする請求項１に記載の端末登録システムとした。
　このようにすることで、通信障害等によってあるサービスサイトへの登録が失敗した際にリトライにより接続される可能性を高めることができる。また、リトライ回数を設けることで、接続可能性の低い（無い）場合のアクセス時間を低減することができる。
　本発明によれば、複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供することができる。
本発明の概要を示す図である。 本発明の第１の実施形態に係る端末登録システムを示す構成図である。 上記第１の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 本発明の第２の実施形態に係る端末登録システムを示す構成図である。 上記第２の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 本発明の第３の実施形態に係る端末登録システムを示す構成図である。 上記第３の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 リトライ制御・進捗状況通知を示すシーケンス図である。 標準技術（ＦＩＤＯ）の特徴を説明する図である。 標準技術（ＦＩＤＯ）において、新規端末の登録を説明する図である。 ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法１を説明する図である。 ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法２を説明する図である。 多数のサービスサイトについて利用可能な状態にする際の課題を説明する図である。 秘密鍵のセキュアな共有技術を説明する図であり、（ａ）は集中型共有方式による共有技術を示す図、（ｂ）は分散型共有方式による共有技術を示す図である。 再登録の利便性向上技術を説明する図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における端末登録システム等について説明する。
［システム構成と処理概要］
　まず、本発明と既存技術との関係性について説明する。
 <秘密鍵のセキュアな共有技術>
　図１４は、秘密鍵のセキュアな共有技術を説明する図であり、図１４（ａ）は集中型共有方式による共有技術を示し、図１４（ｂ）は分散型共有方式による共有技術を示す。
　本人確認情報に基づいて秘密鍵を端末間でセキュアに共有する技術が提案されている（非特許文献３参照）。
　図１４（ａ）に示すように、集中型共有方式では、端末１，２は、キーストア３０に認証鍵を保管しておく。端末１，２は、本人確認情報をもとにアクセス制御を行ってキーストア３０にアクセスし、キーストア３０に保管された同一の鍵を共用する。
　図１４（ｂ）に示すように、分散型共有方式では、登録済み端末１と新規端末２の鍵共有を行っておく。例えば、登録済み端末１は、本人確認情報をもとに新規端末２との間で所有者一致を確認し、所有者一致が確認できた場合には登録済み端末１の認証鍵を新規端末２に複製する。
　上記集中型共有方式および上記分散型共有方式のいずれの共有技術でも、新端末のRegistrationを新たに行わずともＦＩＤＯ認証を利用することができる。しかし、ＦＩＤＯ仕様は、秘密鍵を端末に閉じ込めることを前提としており、前記いずれかの共有技術を利用するためには、ＦＩＤＯ標準仕様に準拠した端末をそのまま利用できず、独自に拡張した端末を利用する必要がある。
 <再登録の利便性向上技術>
　図１５は、再登録の利便性向上技術を説明する図である。
　図１５に示すように、登録済み端末１の秘密鍵で作成した署名を新規端末２に事前に付与しておく。これにより、新規端末２のRegistrationを任意のタイミングかつユーザ作業なしで実施可能とする技術が提案されている（非特許文献４参照）。
　本技術により、ユーザは、新規端末２の初回時に能動的に全てのサービスサイト２１にアクセスしてRegistration作業を行っておかずとも、サービスサイト２１への初回アクセス時に自動的に（ユーザ作業なしに）Registrationが行われる。このため、サービスサイト数に比例したユーザの作業負担がない。しかし、本技術は、自動でRegistrationを行うためにＦＩＤＯプロトコルに拡張が必要であり、また、新規端末２上で署名情報を管理する機能追加が必要である。本技術は、上記図１４の場合と同様に、ＦＩＤＯ標準仕様に準拠した端末をそのまま利用できず、独自に拡張した端末を利用する必要がある。
　本発明は、登録済み端末を用いた複数のサービスサイトに対する新規端末の登録に際し、ユーザ利便性を向上させるものである。
［システム構成と処理概要］
　図１は、本発明の概要を示す図である。
　図１に示すように、端末登録システムは、登録済み端末１のAuthenticator１０が保管するサービスサイト一覧情報１１０と、複数のサービスサイトへの新規端末２のRegistrationを実行する機能部であるRegistration Manager１００（登録機能部）と、を備える。
　サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬ（Uniform Resource Locator）を紐付けて管理するためのＵＲＬ一覧である。サービスサイト一覧情報１１０は、登録済み端末１のAuthenticator１０（認証装置）に保管される。
　Registration Manager１００は、下記のように登録済み端末１と新規端末２との双方を制御する。
　Registration Manager１００は、登録済み端末１から、登録済み端末１のAuthenticator１０が保管しているサービスサイト一覧情報１１０を取得する（図１の符号ａ参照）。
　Registration Manager１００は、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。Registration Manager１００は、上記Registration処理を、サービスサイト一覧情報１１０に保管されたＵＲＬの全サイト分、自動実行する。
　例えば、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、全サービスサイト（サービスサイトＡ２１，サービスサイトＢ２２，…）に対して、登録済み端末１を用いた新規端末２の登録を自動実行する（図１の符号ｂ参照）。
　ここで、Registration Manager１００は、ユーザに対する登録進捗状況の表示や、通信障害等による失敗時にリトライ制御なども実行する（図８で後記する）。図１の例では、Registration Manager１００は、登録済み端末１の秘密鍵１－Ａを用いて登録対象のサービスＡサイトへＦＩＤＯ認証を行う（図１の符号ｃ参照）。そしてRegistration Manager１００は、新規端末２で新規に生成した暗号鍵のRegistration（登録処理）を行う（図１の符号ｄ参照）。
　以上は、サービスサイトＡ２１に対する、登録済み端末１を用いた新規端末２の登録を自動実行する例であるが、サービスサイトＢ２２に対しても同様に処理する（図１の符号ｅ，ｆ参照）。
　このように、Registration Manager１００は、全サービスサイトに対して、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証と、新規端末２で新規に生成した暗号鍵のRegistrationを行う。
　なお、Registration Manager１００は、登録済み端末１側、新規端末２側、登録済み端末１および新規端末２の外部のいずれに配置されてもよい。Registration Manager１００を、登録済み端末１側に配置する例を第１の実施形態で、新規端末２側に配置する例を第２の実施形態で、端末の外部に配置する例を第３の実施形態でそれぞれ説明する。
（第１の実施形態）
　第１の実施形態は、Registration Manager１００を登録済み端末１側に配置する例である。
　図２は、本発明の第１の実施形態に係る端末登録システムを示す構成図である。なお、図２の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。
［端末登録システムの全体構成］
　図２に示すように、本実施形態に係る端末登録システムは、登録済み端末（端末１）、新規端末（端末２）に加え、ネットワーク上に、サービスサイト２０と、ＤＮＳ（Domain Name System）サーバ３０（図３参照）と、を含んで構成される。登録済み端末（端末１）と、新規端末（端末２）と、サービスサイト２０と、ＤＮＳサーバ３０とは、通信ネットワーク（図示省略）で接続されており、相互に通信可能である。
 <サービスサイト>
　サービスサイト２０は、Ｗｅｂアプリケーションサーバ（Web application server）２１１と、ＦＩＤＯサーバ２１２と、を備える。
　Ｗｅｂアプリケーションサーバ２１１は、ソフトウェアの実行環境や連携機能などを持つＷｅｂサーバである。Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２と接続・連携して複雑な処理を行う機能を持つ。Ｗｅｂアプリケーションサーバ２１１は、例えばＥＣ（Electronic Commerce）サイトを運営するサービス事業者が運用するＷｅｂサーバであり、サービスを利用するユーザの登録と認証とを行う。
　ＦＩＤＯサーバ２１２は、ＦＩＤＯ認証をつかさどるものであり、Ｗｅｂアプリケーションサーバ２１１の中で認証を行う部分だけが切り離されてライブラリとして使用される。
 <端末１，２の構成>
　端末１，２は、認証用端末であり、例えばスマートフォン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートフォンを例に採る。
　端末１，２は、通常のアプリケーション等が動作する領域である通常領域と、マルウェア等が混入しないように管理された領域（外部から不正に侵入できないように管理された領域）であるAuthenticator１０内（セキュア領域）とを論理的に備える。
　通常領域は、一般のアプリケーションプログラムが実行される環境である。通常領域は、ユーザエージェント１１と、ＦＩＤＯクライアント１２とが備わる。
　Authenticator１０は、外部から不正に侵入できないように管理された領域に存在し、生体情報（指紋情報など）が保管される。Authenticator１０は、ＣＰＵ（Central Processing Unit）やＯＳ（Operating System）の特権モードで実行され、特定のプログラムや特定の手順によってのみ、Authenticator１０のプログラムの呼び出しやデータへのアクセスが可能となる。
　Authenticator１０は、チャレンジ・レスポンス認証を行うために鍵を認証する。また、生体認証を行ってから鍵を使えるようにするなど、鍵の取り扱いに関する部分を取り扱う。具体的には、Authenticator１０は、指紋認証などの認証画面を表示し、ユーザを認証する。また、Authenticator１０は、サービスサイト２０から取得した乱数、等をユーザ秘密鍵で署名し、サービスサイト２０に送信する。
　ユーザエージェント１１は、ユーザがサービスサイト２０のＷｅｂアプリケーションサーバ２１１にアクセスするためのブラウザ等である。ユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＷｅｂサービスを利用して鍵登録要求および認証要求を発行する。
　ＦＩＤＯクライアント１２は、サービスサイト２０のＦＩＤＯサーバ２１２と対になるものであり、ＦＩＤＯサーバ２１２（ＦＩＤＯのライブラリ）に対して自分のユーザプロトコルを送信し、ＦＩＤＯサーバ２１２との間で認証メッセージをやり取りする。
　ＦＩＤＯクライアント１２は、メッセージの組み立てや、プロトコルの組み立てを行うのに対し、Authenticator１０は、ＦＩＤＯクライアント１２が行うメッセージの組み立てやプロトコルの組み立てのうち、鍵の取り扱いに関する部分を取り扱う。
 <ＦＩＤＯの認証（authentication）／登録（registration）>
・認証（authentication）
　サービスサイト２０のＷｅｂアプリケーションサーバ２１１からの「ユーザ認証の開始」の要求を受けたＦＩＤＯサーバ２１２は、自ら生成した乱数などの情報を、端末１，２のユーザエージェント１１を介してＦＩＤＯクライアント１２に送信する。ＦＩＤＯ認証要求を受信したＦＩＤＯクライアント１２は、Authenticator１０にユーザ登録を要求する。Authenticator１０は、指紋認証などの認証画面を表示し、ユーザを認証する。認証に成功した場合、Authenticator１０は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１から取得した乱数、等を秘密鍵で署名し、サービスサイト２０のＦＩＤＯサーバ２１２に送信する。ＦＩＤＯサーバ２１２は、受信した署名を検証（ユーザを認証）し、認証結果をＷｅｂアプリケーションサーバ２１１に返却する。
・登録（registration）
　サービスサイト２０のＷｅｂアプリケーションサーバ２１１からの「ユーザ登録の開始」の要求を受けたＦＩＤＯサーバ２１２は、自ら生成した乱数などの情報を、端末１，２のユーザエージェント１１を介してＦＩＤＯクライアント１２に送信する。ＦＩＤＯ登録要求を受信したＦＩＤＯクライアント１２は、Authenticator１０にユーザ登録を要求する。Authenticator１０は、指紋などの生体情報の登録画面を表示し、ユーザに生体情報を登録させる。登録が完了すると、Authenticator１０は、公開鍵暗号の鍵ペアを生成してユーザに紐づける。また、公開鍵やサーバから取得した乱数などから、Authenticator１０の秘密鍵で署名生成し、ＦＩＤＯクライアント１２経由でサービスサイト２０のＦＩＤＯサーバ２１２に送信する。ＦＩＤＯサーバ２１２は、受信した署名を検証（Authenticatorの正当性確認）し、ユーザの公開鍵を登録して、その結果をＷｅｂアプリケーションサーバ２１１に返却する。
 <端末１（登録済み端末）>
　登録済み端末１は、Authenticator１０内に、公開鍵１－Ａとペアになる秘密鍵１－Ａと、公開鍵１－Ｂとペアになる秘密鍵１－Ｂと、公開鍵１－Ｃとペアになる秘密鍵１－Ｃと、サービスサイト一覧情報１１０と、を保管する。
　サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬを紐付けて管理する。例えば、図２に示すように、サービスサイト一覧情報１１０は、秘密鍵「0A295BE44F…」とサイトＵＲＬ「https://svcA.com」とを、また秘密鍵「129CC8B6A2..」とサイトＵＲＬ「https://svcB.org」とを、秘密鍵「FE0085B126…」とサイトＵＲＬ「https://svcC.net」とを紐付ける。
　サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬを紐付けに加え、ユーザ名を紐付け対象としてもよい。このようにすれば、複数のユーザ名のユーザが一のＵＲＬを使用したり、逆に、ユーザ名毎に秘密鍵と対象サイトのＵＲＬの組み合わせを変えることができる。
　なお、従来のユーザ認証技術において、秘密鍵と対象サイトのＵＲＬを紐付けて管理するものはなかった。
 <Registration Manager１００>
　本実施形態では、登録済み端末１側に、Registration Manager１００が配置される。
　Registration Manager１００は、登録済み端末１のAuthenticator１０に登録されている全ての秘密鍵について、対象のサービスサイトにログインした上で、新規端末２をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行う。
　以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
　まず、端末登録システムの端末登録方法の動作概要について述べる。
　図２に示すように、Registration Manager１００は、登録済み端末１側に配置されている。
　手順１：Registration Manager１００は、Authenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２～手順４の処理を実行する。
　手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
　手順３：Registration Manager１００は、登録済み端末１の内部Authenticator１０に登録されている秘密鍵を利用して対象のサービスサイト２０にＦＩＤＯ認証を行ってログインし、セッションを確立する。
　手順４：新規端末２をＣＴＡＰによって外部Authenticator１０として用い、秘密鍵のRegistrationを行う。
　より詳細に説明する。Registration Manager１００は、サービスサイト一覧情報１１０を取得することで、サービスサイト一覧情報１１０の秘密鍵を登録済み端末１が持っていることはわかるが、それをサービスサイト２０に提示する手段は持っていない。サービスサイト２０からすれば、登録済み端末１のRegistration Manager１００がアクセスしてきた場合、それがどのユーザであるかは認証できていない状態である。そこで、上記手順３において、Registration Manager１００は、登録済み端末１の内部Authenticator１０に登録されている秘密鍵を利用して対象のサービスサイト２０にＦＩＤＯ認証を行ってログインし、セッションを確立する。次に、上記手順４において、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、秘密鍵のRegistrationを行うことで、新規端末２を登録する、という流れになる。
［制御シーケンス］
　図３は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
　図３おいて、端末１は登録済み端末であり、Authenticator１０内にサービスサイト一覧情報１１０を保管する。また、端末１には、Registration Manager１００が配置されている。端末２は新規端末である。
　ＤＮＳサーバ（Domain Name System）３０は、ドメイン名をＩＰアドレス形式に変換する最もプリミティブな機能に加えて、該当のＵＲＬ上で提供されているサービスのＵＲＬを返すための拡張(ＳＲＶ（SeRVice record）レコード)があり、それを使う。ＤＮＳサーバ３０は、サイトＵＲＬ上で提供されている再登録等を実行するサービスのロケーションをＳＲＶレコードの形式で提供する。
　ユーザは新規端末２の追加、変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）を行う。この場合、新規端末２でＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。つまりＦＩＤＯでは、Ｗｅｂサービス毎に秘密鍵のRegistrationを行う必要がある。
　ユーザの開始操作は、登録済み端末１のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ１０１）、Registration Manager１００は、登録済み端末１のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ１０２）。登録済み端末１のＦＩＤＯクライアント１２は、新規端末２のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ１０３）。登録済み端末１のＦＩＤＯクライアント１２は、ＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ１０４）。
　Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図２参照）の取得要求を送信する（ステップＳ１０５）。
　登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ１０６）。ユーザ確認は、生体情報（指紋、顔、虹彩、静脈）やＰＩＮ（Personal Identification Number）コード認証を用いた情報等のユーザ認証である。
　登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ１０７）。
　以上までが図２の手順１の「サービスサイト一覧情報の取得」である。
　以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図２の手順２～４に対応する；図３の一点鎖線囲み参照）。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０（図２参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリ（query）を送信して、サイト上で提供されている再登録サービスにアクセスするためのＵＲＬ（以下、登録用エンドポイントという）を問合せる（ステップＳ１０８）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信して、Registration Manager１００は登録用エンドポイントを取得する（ステップＳ１０９）。
　Registration Manager１００は、登録済み端末１のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ１１０）。
　登録済み端末１のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ１１１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ１１２）。
　以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、登録済み端末１のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。
　図３の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１の内部Authenticator１０に保管された秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証を行うものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ１１３）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを登録済み端末１のユーザエージェント１１に送信する（ステップＳ１１４）。登録済み端末１のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ１１５）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ１１６）。
　登録済み端末１のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証によりユーザ確認を行う（ステップＳ１１７）。なお、ＦＩＤＯ認証は、全サービスサイトに対して繰り返し行う必要がある。ユーザ負担を減らすため、ステップＳ１１７における生体認証はできるだけ簡便であることが好ましく、例えば指紋による生体認証が挙げられる。また、標準技術（ＦＩＤＯ）の拡張機能では所定時間内の再度の認証は省略することが認められている。ＦＩＤＯは、端末で、生体認証による本人確認と、サーバ認証とを分けており、サービスサイト２０にパスワードを送らないので個人情報が漏れるリスクがない。
　ここで、ＦＩＤＯ標準のAuthenticationオペレーションにおいては、乱数(チャレンジ文字列)は、ＦＩＤＯサーバ２１２が生成（ステップＳ１１３の前段）し、その乱数に対してAuthenticator１０の秘密鍵で署名をして返送する。
　登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名する（ステップＳ１１８）。
　Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ１１９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを登録済み端末１のユーザエージェント１１に送信し（ステップＳ１２０）、ユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ１２１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ１２２）。
　以上、上記ステップＳ１１３～ステップＳ１２２では、登録済み端末１の内部Authenticator１０（登録済みの鍵を保持）を利用してログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ１２３）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と登録済み端末１のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ１２４）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ１２５）。
　図３の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、Registrationを行うものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ１２６）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを登録済み端末１のユーザエージェント１１に送信する（ステップＳ１２７）。登録済み端末１のユーザエージェント１１は、登録済み端末１のＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ１２８）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ１２９）。
　新規端末２のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ１３０）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。
　新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ１３１）。新規端末２のAuthenticator１０は、生成した秘密鍵を登録済み端末１のＦＩＤＯクライアント１２に送信する（ステップＳ１３２）。
　登録済み端末１のＦＩＤＯクライアント１２は、生成した秘密鍵を登録済み端末１のユーザエージェント１１に送信する（ステップＳ１３３）。登録済み端末１のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ１３４）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration ResponseをＦＩＤＯサーバ２１２に送信する（ステップＳ１３５）。
　以上、上記ステップＳ１２６～ステップＳ１３５では、新規端末（端末２）をＣＴＡＰによって外部Authenticatorとして用い、新規に生成した秘密鍵のRegistrationを行う、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ１３６）。Ｗｅｂアプリケーションサーバ２１１は、登録済み端末１のユーザエージェント１１にＦＩＤＯRegistration Requestの登録完了を送信する（ステップＳ１３７）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ１３８）。
　Registration Manager１００は、全サービスサイトに対して、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証と、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ１３９）。
　上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分の繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。また、ユーザに対し登録進捗状況を表示すると、ユーザに対する利便性が向上する。リトライ制御や登録進捗状況の表示制御については、図８で後記する。
　以上説明したように、本実施形態に係る端末登録システムは、登録済み端末１を用いて、複数のサービスサイト２０に対する新規端末２を登録するシステムであり、登録済み端末１は、秘密鍵とサービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報１１０をAuthenticator１０が備える。Registration Manager１００は、登録済み端末１のAuthenticator１０からサービスサイト一覧情報１１０を取得する。そして、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。本実施形態では、登録済み端末１側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１のAuthenticator１０に登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、Registrationを行う。
　これにより、ＦＩＤＯしか認証手段を持たないサービスサイトにおいて、登録済み端末１を用いて新規端末２をRegistrationするユースケースを対象とすることができる。Registration Manager１００が、登録済み端末１のAuthenticator１０から取得したサービスサイト一覧情報１１０をもとに、登録対象のサービスサイトに対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。
　また、Registration Manager１００が登録済み端末１に格納されたサービスサイト一覧を取得し、その全てについてRegistrationを開始することで、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。
　また、Registrationの契機となる各サイトへのアクセスを自動的に実行することで、サービスサイトが増えた時のユーザの作業負担が軽減される。
　本実施形態では、登録済み端末１側にRegistration Manager１００が配置されるので、元々使っていた登録済み端末１に登録結果が表示される。登録済み端末１は、ユーザにとって使いなれた端末である。ユーザは使いなれた登録済み端末１側で登録結果を確認することができる。
（第２の実施形態）
　第２の実施形態は、Registration Manager１００を新規端末２側に配置する例である。
　図４は、本発明の第２の実施形態に係る端末登録システムを示す構成図である。図２と同一構成部分には同一番号を付して重複箇所の説明を省略する。なお、図４の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。
　端末１は、登録済み端末１であり、端末２は、新規端末２である。
　登録済み端末１は、Authenticator１０内に、公開鍵１－Ａとペアになる秘密鍵１－Ａと、公開鍵１－Ｂとペアになる秘密鍵１－Ｂと、公開鍵１－Ｃとペアになる秘密鍵１－Ｃと、サービスサイト一覧情報１１０と、を保管する。
　本実施形態では、新規端末２側に、Registration Manager１００が配置される。
　Registration Manager１００は、登録済み端末１のAuthenticator１０から全サイトのサービスサイト一覧情報１１０を取得し、各サイトについて、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインする。新規端末２は、確立されたセッション上で、自身のAuthenticatorに関するRegistration処理を実行する。
　以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
　まず、端末登録システムの端末登録方法の動作概要について述べる。
　図４に示すように、Registration Manager１００は、新規端末２側に配置されている。
　手順１：Registration Manager１００は、登録済み端末１のAuthenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２～手順４の処理を実行する。
　手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
　手順３：Registration Manager１００は、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、セッションを確立する。
　手順４：新規端末２は、確立されたセッション上で、自身のAuthenticatorに関するRegistration処理を実行する。
［制御シーケンス］
　図５は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
　図５おいて、端末１は登録済み端末であり、Authenticator１０内にサービスサイト一覧情報１１０を保管する。端末２は、新規端末であり、Registration Manager１００が配置されている。
　ユーザの開始操作は、新規端末２のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ２０１）、Registration Manager１００は、新規端末２のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ２０２）。新規端末２のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ２０３）。新規端末２のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ２０４）。
　Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図４参照）の取得要求を送信する（ステップＳ２０５）。
　登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ２０６）。ユーザ確認は、生体情報（指紋、虹彩、静脈）やＰＩＮを用いた情報等のユーザ認証である。
　登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ２０７）。
　以上までが図４の手順１の「サービスサイト一覧情報の取得」である。
　以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図４の手順２～４に対応する；図５の一点鎖線囲み参照）。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０（図４参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリを送信して登録用エンドポイントを問合せる（ステップＳ２０８）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信してRegistration Manager１００は登録用エンドポイントを取得する（ステップＳ２０９）。
　Registration Manager１００は、新規端末２のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ２１０）。
　新規端末２のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ２１１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ２１２）。
　以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、新規端末２のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。
　図５の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１の外部Authenticator１０から全サイトのＵＲＬリストを取得し、各サイトについて、登録済み端末１をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインするものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ２１３）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを新規端末２のユーザエージェント１１に送信する（ステップＳ２１４）。新規端末２のユーザエージェント１１は、新規端末２のＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ２１５）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ２１６）。
　登録済み端末１のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ２１７）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。
　登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名をする（ステップＳ２１８）。
　Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ１１９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを新規端末２のユーザエージェント１１に送信し（ステップＳ２２０）、新規端末２のユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ２２１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ２２２）。
　以上、上記ステップＳ２１３～ステップＳ２２２では、登録済み端末１をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ２２３）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と新規端末２のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ２２４）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ２２５）。
　図５の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、確立されたセッション上で、新規端末２は自身のAuthenticatorに関するRegistration処理を実行するものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ１２６）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを新規端末２のユーザエージェント１１に送信する（ステップＳ２２７）。新規端末２のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ２２８）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ２２９）。
　新規端末２のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ２３０）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。
　新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ２３１）。新規端末２のAuthenticator１０は、生成した秘密鍵を新規端末２のＦＩＤＯクライアント１２に送信する（ステップＳ２３２）。
　新規端末２のＦＩＤＯクライアント１２は、生成した秘密鍵を新規端末２のユーザエージェント１１に送信する（ステップＳ２３３）。新規端末２のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ２３４）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration ResponseをＦＩＤＯサーバ２１２に送信する（ステップＳ２３５）。
　以上、上記ステップＳ２２６～ステップＳ２３５では、確立されたセッション上で、新規端末２は自身のAuthenticatorに関するRegistration処理を実行する、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ２３６）。Ｗｅｂアプリケーションサーバ２１１は、新規端末２のユーザエージェント１１にＦＩＤＯRegistration Requestの登録完了を送信する（ステップＳ２３７）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ２３８）。
　Registration Manager１００は、全サービスサイトに対して、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ２３９）。
　上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分を繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。リトライ制御や登録進捗状況の表示制御については、図８で後記する。
　このように、本実施形態に係る端末登録システムは、新規端末２側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１のAuthenticator１０から全サービスサイトのＵＲＬリストを取得し、各サービスサイトについて、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、新規端末２は、確立されたセッション上で、自身のAuthenticator１０に関するRegistrationを行う。
　これにより、本実施形態では、第１の実施形態と同様の効果、すなわちRegistration Manager１００が、登録済み端末１のAuthenticator１０から取得したＵＲＬ一覧に対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。
　また、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。
　本実施形態では、新規端末２側にRegistration Manager１００が配置されるので、新規端末２に登録結果が表示される。ユーザはいまから使いたい新規端末２側で登録結果を確認することができる。また一般に、新規端末２は、いままで使っていた端末より高機能な場合が多いので、より高機能な新規端末２の資源（例えば高解像度・大画面・高速描画、高速通信など）でRegistrationと登録結果表示を行うことができる。
（第３の実施形態）
　第３の実施形態は、Registration Manager１００を登録済み端末１および新規端末２とは異なる外部装置３側に配置する例である。
　図６は、本発明の第３の実施形態に係る端末登録システムを示す構成図である。図２および図４と同一構成部分には同一番号を付して重複箇所の説明を省略する。なお、図６の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。
　端末１は、登録済み端末１であり、端末２は、新規端末２である。
　登録済み端末１は、Authenticator１０内に、公開鍵１－Ａとペアになる秘密鍵１－Ａと、公開鍵１－Ｂとペアになる秘密鍵１－Ｂと、公開鍵１－Ｃとペアになる秘密鍵１－Ｃと、サービスサイト一覧情報１１０と、を保管する。
　外部装置３は、例えばＰＣ（personal computer）である。外部装置３は、ＰＣのＵＳＢ（Universal Serial Bus）ポートに挿すＵＳＢトークンであってもよい。ＵＳＢトークンは、ＰＣを使うための鍵であり、ＵＳＢトークンがないか有効にされていないと、特定のデータを開けない、あるいはネットワークに接続できない。また、このＵＳＢトークンに、指紋認証などの生体認証手段を設けてもよい。
　外部装置３は、通常領域にユーザエージェント１１と、ＦＩＤＯクライアント１２とを備え、セキュア領域にAuthenticator１０を備える。
　外部装置３のAuthenticator１０は、ＦＩＤＯ標準のAuthenticationオペレーションを実行する端末１，２から見た場合、外部Authenticatorに対応する。
　本実施形態では、登録済み端末１および新規端末２とは異なる外部装置３側に、Registration Manager１００が配置される。
　Registration Manager１００は、登録済み端末１から全サービスサイトのＵＲＬ一覧を取得し、各サイトについて、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistrationを行う。
　以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
　まず、端末登録システムの端末登録方法の動作概要について述べる。
　図６に示すように、Registration Manager１００は、外部装置３側に配置されている。
　手順１：Registration Manager１００は、登録済み端末１のAuthenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２～手順４の処理を実行する。
　手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
　手順３：Registration Manager１００は、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、セッションを確立する。
　手順４：ログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行する。
［制御シーケンス］
　図７は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
　図７おいて、ユーザの開始操作は、外部装置３のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ３０１）、Registration Manager１００は、外部装置３のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ３０２）。外部装置３のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ３０３）。また、外部装置３のＦＩＤＯクライアント１２は、新規端末２のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ３０４）。すなわち、外部装置３は、登録済み端末１のAuthenticator１０と新規端末２のAuthenticator１０との両者の間で、それぞれＣＴＡＰチャネルを確立する。
　外部装置３のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０および新規端末２のAuthenticator１０の間でＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ３０５）。
　Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図７参照）の取得要求を送信する（ステップＳ３０６）。
　登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ３０７）。ユーザ確認は、生体情報（指紋、顔、虹彩、静脈）やＰＩＮを用いた情報等のユーザ認証である。
　登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ３０８）。
　以上までが図６の手順１の「サービスサイト一覧情報の取得」である。
　以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図６の手順２～４に対応する；図７の一点鎖線囲み参照）。
　Registration Manager１００は、取得したサービスサイト一覧情報１１０（図６参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリを送信して登録用エンドポイントを問合せる（ステップＳ３０９）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信してRegistration Manager１００は登録用エンドポイントを取得する（ステップＳ３１０）。
　Registration Manager１００は、外部装置３のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ３１１）。外部装置３のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ３１２）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、サービスサイト２０のＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ３１３）。
　以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、外部装置３のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。
　図７の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１から全サービスサイトのサービスサイト一覧情報１１０を取得し、各サイトについて、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistrationを行うものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ３１４）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを外部装置３のユーザエージェント１１に送信する（ステップＳ３１５）。外部装置３のユーザエージェント１１は、外部装置３のＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ３１６）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ３１７）。
　登録済み端末１のAuthenticator１０は、生体情報（指紋、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ３１８）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。
　登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名をする（ステップＳ１１８）。
　Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ３２０）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを外部装置３のユーザエージェント１１に送信し（ステップＳ３２１）、外部装置３のユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ３２２）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ３２３）。
　以上、上記ステップＳ３１４～ステップＳ３２３では、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ３２４）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と外部装置３のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ３２５）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ３２６）。
　図７の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行するものである。
　サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ３２７）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを外部装置３のユーザエージェント１１に送信する（ステップＳ３２８）。外部装置３のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ３２９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ３３０）。
　新規端末２のAuthenticator１０は、生体情報（指紋、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ３３１）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。
　新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ３３２）。新規端末２のAuthenticator１０は、生成した秘密鍵を外部装置３のＦＩＤＯクライアント１２に送信する（ステップＳ３３３）。
　外部装置３のＦＩＤＯクライアント１２は、生成した秘密鍵を外部装置３のユーザエージェント１１に送信する（ステップＳ３３４）。外部装置３のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ３３５）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ３３６）。
　以上、上記ステップＳ３２７～ステップＳ３３６では、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行する、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。
　サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ３３７）。Ｗｅｂアプリケーションサーバ２１１は、外部装置３のユーザエージェント１１にＦＩＤＯ Registration Requestの登録完了を送信する（ステップＳ３３８）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ３３９）。
　Registration Manager１００は、全サービスサイトに対して、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ３４０）。
　上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分を繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。リトライ制御や登録進捗状況の表示制御については、図８で後記する。
　このように、本実施形態に係る端末登録システムは、登録済み端末１および新規端末２とは異なる外部装置３側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１から全サービスサイトのＵＲＬ一覧を取得し、各サービスサイトについて、登録済み端末１を外部Authenticator１０として用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticator１０として用い、新規にRegistrationを行う。
　これにより、本実施形態では、第１の実施形態および第２の実施形態と同様の効果、すなわち複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。また、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。
　本実施形態では、外部装置３側にRegistration Manager１００が配置されるので、端末側の必要機能を最低限にした機能構成とすることができる。端末のリソースを保つことができる。また、端末の機能上で制約がある場合は、より高機能な外部装置３側で選ぶことも可能である。
［リトライ制御・進捗状況通知］
　次に、リトライ制御・進捗状況通知の例について説明する。
　図８は、リトライ制御・進捗状況通知を示すシーケンス図である。
　Registration Manager１００は、登録済み端末１側、新規端末２側、または端末１，２の外部のいずれに配置されていてもよい。登録対象のサービスサイト２０は、サービスサイトＡ２１，サービスサイトＢ２２，サービスサイトＣ２３であるとする。
　ユーザの開始操作は、Registration Manager１００に送信され（ステップＳ４０１）、Registration Manager１００は、登録済み端末１からサービスサイト一覧情報１１０を取得する（ステップＳ４０２）。そして、Registration Manager１００は、ユーザに登録開始の通知を行う（ステップＳ４０３）。
　なお、ユーザの開始操作からサービスサイト一覧情報１１０の取得に至る具体的なシーケンスについては、図３、図５、および図７により詳述した。
　図８の符号ｇに示すように、端末には、ユーザに進捗状況として「登録開始」および、登録対象サイト数「３」であることが通知される。この通知は、例えば、端末の表示画面において、該当アプリの通知欄に表示される。この例では、「登録開始」「対象：３　完了：０　失敗：０」が表示される。
　Registration Manager１００は、各サービスサイトについて、登録済み端末１または新規端末２をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行う。
　すなわち、Registration Manager１００は、サービスサイトＡ２１への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始し（ステップＳ４０４）、登録済み端末１との間でＦＩＤＯ標準のAuthenticationオペレーションを実行する（ステップＳ４０５）。Registration Manager１００は、サービスサイトＡ２１からＦＩＤＯ認証結果を受信する（ステップＳ４０６）。
　そして、Registration Manager１００は、サービスサイトＡ２１に対しＦＩＤＯ認証登録要求を出力してＦＩＤＯ認証登録を開始し（ステップＳ４０７）、新規端末２との間でＦＩＤＯ標準のRegistrationオペレーションを実行する（ステップＳ４０８）。Registration Manager１００は、サービスサイトＡ２１からＦＩＤＯ認証登録結果を受信する（ステップＳ４０９）。
　なお、ＦＩＤＯ標準のAuthenticationオペレーションおよびＦＩＤＯ標準のRegistrationオペレーションについては、図３、図５、および図７により詳述した。
　Registration Manager１００は、サービスサイトＡ２１への登録が完了すると、ユーザに登録進捗状況の更新を通知する（ステップＳ４１０）。
　図８の符号ｈに示すように、端末には、ユーザに進捗状況として、「登録進捗」「対象：３　完了：１　失敗：０」表示される。
　以下同様に、Registration Manager１００は、サービスサイトＢ２２への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始する（ステップＳ４１１）。
　しかしながら、Registration Manager１００が発行したＦＩＤＯ認証開始要求は、サービスサイトＢ２２に到達していない（図８の符号ｉと×印参照）。通信障害等によりサービスサイトＢ２２へＦＩＤＯ認証開始要求が到達していないと想定される。
　図８の符号ｊに示すように、Registration Manager１００は、サービスサイトＢ２２からの応答がない場合、一定時間後に一回目のリトライを実行する。
　Registration Manager１００は、再度、サービスサイトＢ２２に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４１２）。
　リトライによりサービスサイトＢ２２へのＦＩＤＯ認証開始要求の送信が成功し、登録済み端末１との間でＦＩＤＯ標準のAuthenticationオペレーションを実行する（ステップＳ４１３）。Registration Manager１００は、サービスサイトＢ２２からＦＩＤＯ認証結果を受信する（ステップＳ４１４）。
　そして、Registration Manager１００は、サービスサイトＢ２２に対しＦＩＤＯ認証登録要求を出力してＦＩＤＯ認証登録を開始し（ステップＳ４１５）、新規端末２との間でＦＩＤＯ標準のRegistrationオペレーションを実行する（ステップＳ４１６）。Registration Manager１００は、サービスサイトＢ２２からＦＩＤＯ認証登録結果を受信する（ステップＳ４１７）。
　Registration Manager１００は、サービスサイトＢ２２への登録が完了すると、ユーザに登録進捗状況の更新を通知する（ステップＳ４１８）。
　図８の符号ｋに示すように、端末には、ユーザに進捗状況として、「登録進捗」「対象：３　完了：２　失敗：０」表示される。
　次に、Registration Manager１００は、サービスサイトＣ２３への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始する（ステップＳ４１９）。
　しかしながら、Registration Manager１００が発行したＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｌと×印参照）。この段階では、通信障害等によりサービスサイトＣ２３へＦＩＤＯ認証開始要求が到達していないと想定される。
　図８の符号ｍに示すように、Registration Manager１００は、サービスサイトＣ２３からの応答がない場合、一定時間後に一回目のリトライを実行する。
　Registration Manager１００は、一回目のリトライで、サービスサイトＣ２３に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４２０）。
　一回目のリトライによるサービスサイトＣ２３へのＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｎと×印参照）。
　図８の符号ｏに示すように、Registration Manager１００は、サービスサイトＣ２３からの応答がない場合、一定時間後に二回目のリトライを実行する。
　Registration Manager１００は、二回目のリトライで、サービスサイトＣ２３に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４２１）。
　二回目のリトライによってもサービスサイトＣ２３へのＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｐと×印参照）。この場合、重度の通信障害があるか、サービスサイトＣ２３がネットワークに接続されていないことが想定される。
　図８の符号ｑに示すように、Registration Manager１００は、一定回数（ここでは二回）のリトライ後、サービスサイトＣ２３への登録失敗と判断し、サービスサイトＣ２３への登録処理を終了する。
　Registration Manager１００は、サービスサイトＣ２３への登録終了（登録失敗）を通知する（ステップＳ４２２）。
　図８の符号ｒに示すように、端末には、ユーザに進捗状況として、「登録完了」「対象：３　完了：２　失敗：１」表示される。この場合、図８の符号ｓに示すように、登録に失敗したサービスサイトを明示するとよりよい。例えば、登録失敗したサービスサイトＣ２３のＵＲＬを表示する。
　このように、Registration Manager１００は、ユーザに対して、各サービスサイトへの登録進捗状況を通知することで、ユーザはサービスサイトへの登録進捗状況（対象サイト数、登録完了数、登録失敗）を確認することができる。また、失敗したサイトを明示することで、有効でないサイトを確認することができる。
　また、Registration Manager１００は、各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行うことで、通信障害等によってあるサービスサイトへの登録が失敗した際にリトライにより接続される可能性を高めることができる。また、リトライ回数を設けることで、接続可能性の低い（無い）場合のアクセス時間を低減することができる。
　なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、明細書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
　１　登録済み端末（端末）
　２　新規端末（端末）
　３　外部装置
　１０　Authenticator（認証装置）
　１１　ユーザエージェント
　１２　ＦＩＤＯクライアント
　２０，２１，２２，２３，２４　サービスサイト
　３０　ＤＮＳサーバ
　１００　Registration Manager（登録機能部）
　１１０　サービスサイト一覧情報
　２１１　Ｗｅｂアプリケーションサーバ
　２１２　ＦＩＤＯサーバ

Claims (7)

  1. 　秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、
    　登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、
    　前記登録済み端末は、
    　前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorが備え、
    　前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、前記新規端末で新規に生成した暗号鍵のRegistrationを行う登録機能部
    　を備えることを特徴とする端末登録システム。
  2. 　前記登録機能部は、前記登録済み端末側に配置され、
    　前記登録済み端末の前記Authenticatorに登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、前記新規端末をＣＴＡＰ（Client To Authenticator Protocol）によって外部Authenticatorとして用い、Registrationを行う
    　ことを特徴とする請求項１に記載の端末登録システム。
  3. 　前記登録機能部は、前記新規端末側に配置され、
    　前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインし、
    　前記新規端末は、確立されたセッション上で、自身のAuthenticatorに関するRegistrationを行う
    　ことを特徴とする請求項１に記載の端末登録システム。
  4. 　前記登録機能部は、前記登録済み端末および前記新規端末とは異なる外部装置に配置され、
    　前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、前記新規端末を外部Authenticatorとして用い、新規にRegistrationを行う
    　ことを特徴とする請求項１に記載の端末登録システム。
  5. 　前記登録機能部は、
    　ユーザに対して、各サービスサイトへの登録進捗状況を通知する
    　ことを特徴とする請求項１に記載の端末登録システム。
  6. 　前記登録機能部は、
    　各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行う
    　ことを特徴とする請求項１に記載の端末登録システム。
  7. 　秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、
    　前記登録済み端末は、
    　前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorに有し、
    　登録機能部は、
    　前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証するステップと、
    　前記新規端末で新規に生成した暗号鍵のRegistrationを行うステップと、
    　を実行する端末登録方法。
PCT/JP2019/004088 2018-02-06 2019-02-05 端末登録システムおよび端末登録方法 WO2019156081A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/964,806 US11483159B2 (en) 2018-02-06 2019-02-05 Terminal registration system and terminal registration method
US17/824,488 US11917076B2 (en) 2018-02-06 2022-05-25 Terminal registration system and terminal registration method
US17/824,670 US20220286297A1 (en) 2018-02-06 2022-05-25 Terminal registration system and terminal registration method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-018867 2018-02-06
JP2018018867A JP6600369B2 (ja) 2018-02-06 2018-02-06 端末登録システムおよび端末登録方法

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US16/964,806 A-371-Of-International US11483159B2 (en) 2018-02-06 2019-02-05 Terminal registration system and terminal registration method
US17/824,488 Division US11917076B2 (en) 2018-02-06 2022-05-25 Terminal registration system and terminal registration method
US17/824,670 Division US20220286297A1 (en) 2018-02-06 2022-05-25 Terminal registration system and terminal registration method

Publications (1)

Publication Number Publication Date
WO2019156081A1 true WO2019156081A1 (ja) 2019-08-15

Family

ID=67548096

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/004088 WO2019156081A1 (ja) 2018-02-06 2019-02-05 端末登録システムおよび端末登録方法

Country Status (3)

Country Link
US (3) US11483159B2 (ja)
JP (1) JP6600369B2 (ja)
WO (1) WO2019156081A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220166623A1 (en) * 2019-04-25 2022-05-26 CopSonic Hardware authentication token with remote validation
US11777917B2 (en) 2020-10-15 2023-10-03 Cisco Technology, Inc. Multi-party cloud authenticator

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6600369B2 (ja) * 2018-02-06 2019-10-30 日本電信電話株式会社 端末登録システムおよび端末登録方法
JP2021069402A (ja) * 2019-10-29 2021-05-06 株式会社三洋物産 遊技機
US20230141952A1 (en) * 2020-11-09 2023-05-11 Medical Data Networks, LLC System and method for third-party password-less access to a secure database
EP4080390A1 (en) * 2021-04-19 2022-10-26 Thales DIS France SA A method for granting a user access through a user access device hosting a client application to a service coming from a set of services of a server application hosted by a distant server

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016521403A (ja) * 2013-03-22 2016-07-21 ノック ノック ラブズ， インコーポレイテッドＮｏｋ Ｎｏｋ Ｌａｂｓ， Ｉｎｃ． 高度な認証技術及びその応用
JP2017152877A (ja) * 2016-02-24 2017-08-31 日本電信電話株式会社 電子鍵再登録システム、電子鍵再登録方法およびプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105474573B (zh) * 2013-09-19 2019-02-15 英特尔公司 用于同步并恢复参考模板的技术
US9503894B2 (en) * 2014-03-07 2016-11-22 Cellco Partnership Symbiotic biometric security
JP6600369B2 (ja) * 2018-02-06 2019-10-30 日本電信電話株式会社 端末登録システムおよび端末登録方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016521403A (ja) * 2013-03-22 2016-07-21 ノック ノック ラブズ， インコーポレイテッドＮｏｋ Ｎｏｋ Ｌａｂｓ， Ｉｎｃ． 高度な認証技術及びその応用
JP2017152877A (ja) * 2016-02-24 2017-08-31 日本電信電話株式会社 電子鍵再登録システム、電子鍵再登録方法およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NISHIMURA HIDEO ET AL.: "A study on key Re-registration due to change of device for Mobile-Device-based public key authentication", IEICE TECHNICAL REPORT, vol. 117, no. 460, 22 February 2018 (2018-02-22), pages 69 - 74 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220166623A1 (en) * 2019-04-25 2022-05-26 CopSonic Hardware authentication token with remote validation
US11777917B2 (en) 2020-10-15 2023-10-03 Cisco Technology, Inc. Multi-party cloud authenticator

Also Published As

Publication number Publication date
JP6600369B2 (ja) 2019-10-30
US20210058256A1 (en) 2021-02-25
US11917076B2 (en) 2024-02-27
US20220286297A1 (en) 2022-09-08
JP2019140423A (ja) 2019-08-22
US11483159B2 (en) 2022-10-25
US20220286296A1 (en) 2022-09-08

Similar Documents

Publication Publication Date Title
JP6600369B2 (ja) 端末登録システムおよび端末登録方法
EP3420677B1 (en) System and method for service assisted mobile pairing of password-less computer login
JP5375976B2 (ja) 認証方法、認証システムおよび認証プログラム
JP2017107396A (ja) 権限委譲システム、情報処理装置、認可サーバ、制御方法およびプログラム
WO2013119967A1 (en) Systems and methods for password-free authentication
WO2016068916A1 (en) Active authentication session transfer
US11811750B2 (en) Mobile device enabled desktop tethered and tetherless authentication
US20220303268A1 (en) Passwordless login
US11245681B2 (en) Authentication in a multi-tenant environment
US11849053B2 (en) Automation of user identity using network protocol providing secure granting or revocation of secured access rights
JPWO2020070807A1 (ja) 認証システム、認証方法、アプリケーション提供装置、認証装置、認証用プログラム
US20240039729A1 (en) Efficient transfer of authentication credentials between client devices
US20240146533A1 (en) Enhanced login processes using proprietary security and protocol for sharing and managing personal information
JP7079528B2 (ja) サービス提供システム及びサービス提供方法
KR100993333B1 (ko) 인터넷 접속 도구를 고려한 사용자 인증 방법 및 시스템
JP2019046133A (ja) 情報処理装置、制御方法、およびプログラム
CA2877604C (en) System and method of resolving a domain name
JP6080282B1 (ja) 認証処理システム、認証補助サーバ及びウェブ表示プログラム
KR20140043628A (ko) 보안 로그인 처리 방법
JP5749222B2 (ja) アクセス許可制御システム、アクセス許可制御方法
JP7323191B2 (ja) 位置情報を用いた認証システム
JP2012079285A (ja) 二要素ユーザ認証システム、およびその方法
JP2008217151A (ja) 認証代理装置、認証代理方法、及び認証代理プログラム
JP2013003865A (ja) サービス提供システム、認証サーバ、サービス提供装置およびプログラム
JP2014029704A (ja) 認証制御装置、認証制御方法、プログラム、及び記録媒体

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19751073

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19751073

Country of ref document: EP

Kind code of ref document: A1