JP7412725B2 - Authentication method and authentication device - Google Patents

Description

The present invention relates to an authentication method and an authentication device .

Nowadays, it is possible to receive a variety of web-based services using communication terminal devices. In order to identify a user who enjoys a service, authentication using user identification information (ID) registered at the time of sign-up and a password to prevent impersonation is widely performed. In authentication using a user ID and password, the user himself/herself must be careful not to leak the password. Complicated password management can lead to careless password settings. As disclosed in Patent Document 1, methods such as using biometric information to omit password input have been adopted, but it is necessary to introduce highly accurate biometric information reading devices into many communication terminals. That is difficult.

JP2018-018331A

In addition to preventing leakage of user IDs and passwords by users themselves, service providers must also safely manage confidential information including user IDs and passwords containing biometric information. When a service provider centralizes and manages users' confidential information, there is a risk of information leakage or asset outflow due to hacking, operational errors, etc., depending on the scope of responsibility of the service provider. In fact, many cases have been reported in which hundreds to tens of millions of pieces of confidential information are leaked from service providers, and this has become a serious social problem.

Nowadays, the number of services that can be enjoyed using communication terminal devices is not only Internet banking but also the management of various assets of users due to FinTech related technology. The risk of confidential information leakage is not only a problem for service providers and their users, but also has a large impact on the entire economy. An important issue for online services related to asset management is to provide technology that reduces these risks without sacrificing the high level of convenience.

The present invention has been made in view of the above circumstances, and it is an object of the present invention to provide a highly reliable authentication method and authentication device that can be easily introduced and does not require the input of a password or the like.

The authentication method of the present disclosure is an authentication method that performs authentication between a first device related to a person to be authenticated and a second device related to a certifier. The plurality of processing nodes correspond to the attribution source for recording that a predetermined type of token, which is a digital asset that can be transferred between addresses, belongs to an address based on private key information. Using a distributed database network system configured to perform verification and approval operations based on electronic signatures obtained from private key information, and store information by distributing the results of the operations to a plurality of storage media, The second device authenticates the first device based on whether the plurality of processing nodes of the distributed database network system can confirm the attribution of the token to the address based on the private key information of the first device. do.

In the authentication method of the present disclosure, the ownership of the token is confirmed by a smart contract that discloses the token transaction history for each address based on the private key information of the first device.

In the authentication method of the present disclosure, the second device may impose a time limit on the data specified by the specification information.

In the authentication method of the present disclosure, the second device transmits specification information specifying arbitrary data in response to an authentication request from the first device, and the first device receives the specification information. receiving an electronic signature based on the private key information given to the specified data, and receiving the public key information of the first device based on the address based on the private key information of the first device corresponding to the authentication request; The first method is determined based on whether it is possible to confirm, using the derived public key information, that the received electronic signature is valid and that the token belongs to the address of the first device. 1. Authenticate one device.

The authentication device of the present disclosure is configured of a plurality of processing nodes and a storage medium that are connected to each other via a network, and the plurality of processing nodes assigns a digital asset that can be transferred between addresses to an address based on private key information. A transaction for recording the ownership of a predetermined type of token is verified and approved based on an electronic signature obtained from private key information corresponding to the source of ownership, and the results of the calculation are stored in multiple memory locations. A communication unit that sends and receives information to and from a distributed database network system that is configured to hold information distributed over media; and an authentication unit that authenticates the request source based on whether or not the plurality of processing nodes of the distributed database network system can confirm the attribution of the token to the address.

In one embodiment of the present disclosure, authentication is performed using a system called Blockchain, which is a distributed database network that is composed of multiple processing nodes and storage media and stores information by distributing calculation results to multiple storage media. It will be done. In a distributed database network, each node verifies recorded information, so-called transactions, for recording the attribution of predetermined digital information (for example, virtual currency, etc.) based on an electronic signature obtained from private key information corresponding to the attribution source. and perform the calculation to approve.

Therefore, for "things" (things or people) that can send transactions to a distributed database network and that can be the source of digital information, it is established that there is a link between the "thing" itself and the identification information that identifies the "thing". If possible, it can be said that legitimacy is sufficiently guaranteed. Here, in a distributed database network, the identification information of the "thing" to which digital information belongs, the so-called address, is represented by a sequence of numbers (alphanumeric characters) and made public to the general public, and the identification information alone can be distributed. Robust authentication can be achieved by combining this with various methods to prove that identification information belongs to that "thing."

In an embodiment of the present disclosure, as a method of proving that identification information belongs to the "thing", for example, proving whether private key information is stored or not based on whether or not the same identification information can be derived. This can be used to prove attribution. Whether or not it can be derived is determined not only by identification information such as a so-called address, but also by an electronic signature. It does not matter whether the information is digital or analog, as long as it can be created only when private key information is stored. It may be a keyword that can be answered only by the person who has memorized the private key information, it may be an image that only the person who is being authenticated can create, or it may be a question that only the person who is being authenticated can answer correctly. good.

In an embodiment of the present disclosure, for example, specifically, for data specified from the authenticating device to the authenticated device, an electronic signature created based on the private key information of the authenticated device is created based on the public key information of the authenticated device. It is verified whether or not it can be confirmed that the device is legitimate based on the , and whether or not there is a digital asset associated with the address of the device to be authenticated. If it can be confirmed that the authenticated device legitimately owns the digital asset, it can be said that the authenticated person can legitimately carry out the procedure. Thereby, authentication can be performed without a user ID and password from the device to be authenticated, and without distribution of a secret key. The validity of the electronic signature may not be confirmed by the authentication device itself, but may be executed by a specific processing node in the distributed database network, that is, by a contract.

In one embodiment of the present disclosure, verification and approval based on electronic signatures are used to move a digital asset from the authenticating device to the authenticating device, and the digital asset is again linked in a transaction from the authenticating device to the authenticating device. If it can be confirmed, it can be said that the person being authenticated can legitimately carry out the procedure. Thereby, authentication can be performed without a user ID and password from the device to be authenticated, and without distribution of a secret key.

In one embodiment of the present disclosure, a script that describes the movement of digital information in recorded information can set a deadline for the authority to decide on the movement of digital information.

In one embodiment of the present disclosure, in a script that describes the movement of digital information in recorded information, it is possible to add not only an electronic signature but also a predetermined password to the authority to decide the movement of digital information.

According to the authentication method of the present disclosure, as long as the device to be authenticated securely holds the private key, there is no need to input a user ID password. Verification and approval of recorded information using an electronic signature based on a private key is highly reliable because it is performed while a large number of people verify each other in a distributed database network. The authenticated device only needs to be able to create recorded information and attach electronic signatures, so it can be easily incorporated into a computer program for providing services that require authentication, and it is easy to introduce it into services. .

FIG. 2 is an explanatory diagram showing an overview of an authentication method in the authentication system of the present disclosure. FIG. 2 is a block diagram showing the configuration of a terminal device. FIG. 2 is a block diagram showing the configuration of a processing device corresponding to a node of a distributed DB network. FIG. 2 is a block diagram showing the configuration of an authentication server device. FIG. 3 is a sequence diagram showing an example of an authentication processing procedure in the first embodiment. It is an explanatory diagram showing an initial state. FIG. 3 is a diagram illustrating an example of the content of a transaction generated by an authentication server device. FIG. 3 is a diagram illustrating an example of the content of a transaction after a signature has been added. FIG. 6 is a diagram showing the state after the transaction is sent from the authentication server device. FIG. 6 is a diagram showing the state after the transaction is sent from the authentication server device. FIG. 3 is a diagram illustrating an example of the content of a transaction generated by a terminal device. FIG. 3 is a diagram illustrating an example of the content of a transaction after a signature has been added. FIG. 3 is a diagram showing a state after a transaction is sent from a terminal device. FIG. 3 is a diagram showing a state after a transaction is sent from a terminal device. It is a diagram showing the flow of authentication tokens in a distributed DB network. FIG. 2 is an explanatory diagram showing an example of the contents of a script including setting a time limit. FIG. 2 is an explanatory diagram showing an example of the contents of a one-time password script. 7 is a sequence diagram illustrating an example of an authentication processing procedure in Embodiment 2. FIG. FIG. 7 is a sequence diagram illustrating an example of an authentication processing procedure in Embodiment 3;

Hereinafter, an authentication system according to the present disclosure will be described based on drawings showing embodiments.

FIG. 1 is an explanatory diagram showing an overview of an authentication method in an authentication system 100 of the present disclosure. Authentication system 100 includes a terminal device 1, an authentication server device 2, and a distributed DB network 3. The terminal device 1, the authentication server device 2, and the distributed DB network 3 can communicate with each other via the network N.

In the distributed DB network 3, a plurality of processing devices each having a storage medium and a processor are communicatively connected to each other, one or more processing devices constitute a node, and each of the processing devices stores information in a storage medium between the nodes. Constructed by verifying information. The distributed DB network 3 is a so-called distributed ledger, and may be, for example, one called Blockchain.

Authentication system 100 includes a network N. The network N includes a public communication network that is the so-called Internet, a carrier network provided by a carrier operator, a wireless communication network, and the like. Each node (processing device 300 forming a node) in the distributed DB network 3 may send and receive data to and from each other via the network N, or may send and receive data to and from each other directly.

In the authentication system 100 of the present disclosure, the terminal device 1 itself or the user using the terminal device 1 is authenticated based on the presence of a token in the distributed DB network 3. The terminal device 1 can attribute tokens on the distributed DB network 3 to itself or share them with others based on secret information in the distributed DB network 3 stored by the terminal device 1 itself or stored by the user. It can be attributed to. This attribution is specified in the transaction, and the transaction has been verified by the node based on the private key information related to the terminal device 1. A terminal device 1 or its user that can record a transaction in the distributed DB network 3 and can be the source of digital information is the terminal device 1 or the user who owns the address (wallet address) on the distributed DB network 3. If it can be proven that the owner is a legitimate owner, it can be said that its legitimacy is sufficiently guaranteed through verification in the distributed DB network 3.

Hereinafter, multiple embodiments of the authentication system 100 of the present disclosure will be listed using various methods to prove that the address in the distributed DB network 3 belongs to the terminal device 1 or the user of the terminal device 1. explain. Note that the following embodiments are illustrative in all respects.

(Embodiment 1)
In the authentication method of the first embodiment, the authentication server device 2 executes authentication processing in response to an authentication request from the terminal device 1 using a transaction related to the exchange of tokens managed in the distributed DB network 3. . At this time, the terminal device 1 and the authentication server device 2 each perform processing using an address (wallet address) in the distributed DB network 3 created based on the private key. The authentication server device 2 holds a token (for example, 1 satoshi, which is the minimum unit) used for authentication in association with an address. The authentication server device 2 authenticates the terminal device 1 with the electronic signature by verifying the validity of the electronic signature necessary for transmitting the transaction of the authentication token using the distributed DB network 3.

FIG. 2 is a block diagram showing the configuration of the terminal device 1. As shown in FIG. The terminal device 1 is a communication terminal device such as a personal computer, a smartphone, or a tablet terminal, and includes a processing section 10, a storage section 11, a communication section 12, a display section 13, and an operation section 14.

The processing unit 10 uses a processor such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), a memory, and the like. Note that the processing unit 10 may be configured as one piece of hardware (SoC: System On a Chip) in which a processor, a memory, and further the storage unit 11 and the communication unit 12 are integrated. The memory of the processing unit 10 at least temporarily stores an address based on the private key, a public key, and the like. The processing unit 10 executes the authentication process according to the procedure described below based on the application program 1P stored in the storage unit 11. Note that the application program 1P is a program for other services used by the user that incorporates an authentication processing part to be described later.

The storage unit 11 uses a flash memory, and stores programs and data referenced by the processing unit 10, including the application program 1P. The application program 1P causes the general-purpose terminal device 1 to function as the authenticated device (prover) of the first embodiment. The above-mentioned private key may be stored in the storage unit 11, but it may also be stored in other storage media (including a USB memory, a two-dimensional barcode, an image that can be outputted, the user's own memory, etc.) It is desirable that the processing unit 10 be able to temporarily read the public key based on the private key, the address, or the private key itself from the storage medium.

The communication unit 12 is a communication module that realizes a communication connection to the network N. The communication unit 12 uses a network card, a wireless communication device, or a carrier communication module.

The display unit 13 uses a display device such as a liquid crystal panel or an organic EL display. The operation unit 14 is an interface that accepts user operations, and uses physical buttons, a touch panel device with a built-in display, a speaker, a microphone, and the like. The operation unit 14 may accept operations on the screen displayed on the display unit 13 using physical buttons or a touch panel, or may recognize operation details from input audio using a microphone and interact with audio output from a speaker. The operation may be accepted in the format.

FIG. 3 is a block diagram showing the configuration of a processing device 300 corresponding to a node of the distributed DB network 3. As shown in FIG. The processing device 300 includes a processing section 30, a storage section 31, and a communication section 32. The processing device 300 may be a server computer, a desktop or laptop personal computer, or a communication terminal device such as a smartphone. Further, if the processing device 300 is a device that includes at least a processing section 30 and a communication section 32, a part of the processing section 30 can constitute part or all of a node.

The processing unit 30 uses a processor such as a CPU or GPU, a memory, and the like. The processing unit 30 may be configured as one piece of hardware that integrates a processor, a memory, and further the storage unit 31 and the communication unit 32. It is preferable that the memory of the processing unit 30 stores a private key unique to each processing device 300. The processing unit 30 then executes each process based on the node program stored in the storage unit 31 and causes the general-purpose computer to function as a node in the distributed DB network 3.

The storage unit 31 stores programs and data referenced by the processing unit 30 using a hard disk or flash memory. The above-mentioned private key may be stored in the storage unit 31. The storage unit 31 stores the public key and address based on the private key.

The communication unit 32 is a communication module that realizes mutual communication between the processing devices 300. The communication unit 32 uses a network card, an optical communication device, a wireless communication device, or the like.

FIG. 4 is a block diagram showing the configuration of the authentication server device 2. As shown in FIG. The authentication server device 2 uses a server computer and includes a processing section 20, a storage section 21, and a communication section 22.

The processing unit 20 uses a processor such as a CPU or GPU, a memory, and the like. The processing unit 20 receives an authentication request from the terminal device 1 based on the authentication program 2P stored in the storage unit 21, and executes an authentication process to be described later. The authentication program 2P causes a general-purpose server computer to function as the authentication device (verifier) of the first embodiment.

The storage unit 21 uses a hard disk or flash memory to store programs and data referenced by the processing unit 20, including the authentication program 2P. Since the authentication server device 2 side also uses an address based on the private key and a public key, the private key may be stored in the storage unit 21, but like the terminal device 1, it may be stored separately in another storage medium and the processing unit 20 is preferably able to temporarily read the public key based on the private key, the address, or the private key itself from the storage medium.

The communication unit 22 is a communication module that realizes communication connection to the network N. The communication unit 22 uses a network card, a wireless communication device, or a carrier communication module.

The processing executed in the authentication system 100 having such a hardware configuration will be explained. FIG. 5 is a sequence diagram illustrating an example of an authentication processing procedure in the first embodiment.

The processing unit 10 of the terminal device 1 generates a secret key for the distributed DB network 3 in advance (step S101), and generates an address that corresponds one-to-one to the generated secret key (step S102).

On the authentication server device 2 side, a secret key for the distributed DB network 3 is generated in advance by the processing unit 20 (step S201), and an address is generated based on the generated secret key and stored (step S202). . Note that step S202 may generate an address each time an authentication request is received. The processing unit 20 holds an authentication token for its own address on the distributed DB network 3.

The processing unit 10 of the terminal device 1 transmits an authentication request including the address generated in step S102 from the communication unit 12 to the authentication server device 2 (step S103).

In the authentication server device 2, the communication unit 22 receives the authentication request (step S203). This starts the authentication process. The processing unit 20 generates a transaction for transmitting an authentication token from its own address to the address included in the received authentication request, that is, the address of the terminal device 1 (step S204). The processing unit 20 adds an electronic signature based on its own private key to the generated transaction (step S205), transmits the generated transaction to the distributed DB network 3 (step S206), and also sends authentication token information. is transmitted to the terminal device 1 (step S207).

In the distributed DB network 3, when any node receives a transaction transmitted from the authentication server device 2 (step S301), each node verifies and approves the received transaction (step S302). Verification and approval of the transaction in step S302 includes the process of verifying the validity based on the signature included in the transaction, the consistency with the previous transaction based on the hash etc. included in the transaction, and the process of verifying the validity of the transaction based on the signature included in the transaction, the process of verifying the consistency with the previous transaction based on the hash etc. included in the transaction, and the process of verifying these results between multiple nodes. including the processing that you agree to. This means that the authentication token has been moved from the address based on the private key of the authentication server device 2 to the address based on the private key of the terminal device 1 that is the source of the authentication request.

In the terminal device 1, when the communication unit 12 receives the authentication token information transmitted from the authentication server device 2 (step S104), the processing unit 10 changes the address from its own address to the address based on the private key information of the authentication server device 2. A transaction for transmitting an authentication token is generated (step S105). The processing unit 10 writes an electronic signature based on its own private key to the generated transaction (step S106), transmits the generated transaction to the distributed DB network 3 (step S107), and also sends the authentication token information. It is transmitted to the authentication server device 2 (step S108).

In the distributed DB network 3, when any node receives a transaction transmitted from the terminal device 1 (step S303), each node verifies and approves the received transaction (step S304). By verifying and approving the transaction in step S304, the authentication token is moved from the address based on the private key of the terminal device 1 that made the authentication request to the address based on the private key of the authentication server device 2, that is, returned.

In the authentication server device 2, when the communication unit 22 receives the information on the authentication token sent from the terminal device 1 (step S208), the processing unit 20 confirms that the authentication token has been sent to its own address. Confirm on the distributed DB network 3 (step S209). The processing unit 20 transmits the authentication result based on whether or not the verification was successful from the communication unit 22 to the terminal device 1 (step S210).

The terminal device 1 receives the authentication result (step S109) and ends the authentication process.

The processing procedure shown in the sequence diagram of FIG. 5 will be described in detail with reference to the drawings. FIG. 6 is an explanatory diagram showing the initial state. The initial state indicates the state of the authentication system 100 before the authentication request is transmitted from the terminal device 1 to the authentication server device 2. For ease of explanation, in the figure, the terminal device 1 is referred to as "A" as the person to be authenticated (Prover), and the authentication server device 2 is referred to as "B" as the authenticator (Verifier). In the initial state after step S102 and step S202, the terminal device 1 and the authentication server device 2 respectively send an address based on the secret key to the distributed DB network 3 (address A in the figure: "1KfpsrWCRBSZ8...", B's address: "18Wk9BL4NW5vk...") is generated and stored. As shown in FIG. 6, the authentication server device 2 stores an authentication token, that is, an authentication UTXO (unused transaction output) in the distributed DB network 3 in association with its own address. The authentication UTXO includes a lock script (OP_DUP OP_HASH160 <B's pub key hash> OP_EQUALVERIFY OP_CHECKSIG), such as a hash of the public key corresponding to its own address, as an output script. Note that the transaction scripts shown in FIGS. 6 and 7 and subsequent figures are based on the Bitcoin protocol.

FIG. 7 is a diagram showing an example of the content of a transaction generated by the authentication server device 2. As shown in FIG. As shown in FIG. 7, the transaction generated in step S204 (indicated by the symbol txA in FIG. 7) first includes the secret of the terminal device 1 notified from the terminal device 1 (A) in the output (ouput). The hash of the public key corresponding to the address based on the key information is included in the output as information that refers to the destination. The transaction txA includes information (transaction hash, index, etc.) in the input based on the UTXO associated with the address of the authentication server device 2(B) (not shown). At this point, the signature part of the input script is temporarily replaced with other information (the hash of the public key of the authentication server device 2).

FIG. 8 is a diagram showing an example of the contents of the transaction txA after the signature has been added. As shown in FIG. 8, the transaction txA by adding the signature in step S205 includes an electronic signature (B's signature) created based on the private key of the authentication server device 2 from the hash of the transaction TxA (FIG. 7) before signing. A public key (B's pub key) based on the private key of the authentication server device 2 is assigned. This electronic signature proves that the creator of this transaction TxA is the authentication server device 2.

FIG. 9 is a diagram showing the state after the transaction txA is sent from the authentication server device 2. The transaction txA sent from the authentication server device 2 is broadcast on the distributed DB network 3. Additionally, the authentication server device 2 uses a transaction ID (tx id) and an output index for specifying the output in the transaction txA specified by the transaction ID as specific information for specifying the authentication token sent to the terminal device 1. (output index) is transmitted as shown in FIG. This allows the terminal device 1 to specify the authentication UTXO associated with its own address.

FIG. 10 is a diagram showing the state after the transaction txA is sent from the authentication server device 2. Transaction txA from the authentication server device 2 shown in FIG. 9 is verified and approved by the distributed DB network 3 (S302). As a result, an authentication token, that is, an authentication UTXO (unused transaction output) is associated (moved) with the address of the terminal device 1 (A) on the distributed DB network 3. The UTXO for authentication corresponds to the output of transaction txA.

FIG. 11 is a diagram showing an example of the content of a transaction generated by the terminal device 1. As shown in FIG. Upon receiving the authentication token information sent from the authentication server device 2 (S104), the terminal device 1 specifies the authentication UTXO shown in FIG. public key) can also be identified. The processing unit 10 of the terminal device 1 generates a transaction (indicated by the symbol txB in FIG. 11) as shown in FIG. 11 (step S105). The transaction txB generated here first includes in the output the hash of the public key corresponding to the address of the authentication server device 2 as information referring to the destination. The input of transaction txB includes information from the specified authentication UTXO (hash of transaction txA, tx id, etc.) (not shown). At this point as well, the signature part of the input script is temporarily replaced with other information (the hash of the public key of the terminal device 1).

FIG. 12 is a diagram showing an example of the contents of the transaction txB after the signature has been added. As shown in FIG. 12, as a result of the signature addition process in step S106, transaction txB includes an electronic signature (A's signature) created based on the private key of terminal device 1 from the hash of transaction TxB (FIG. 11) before signing. , a public key (A's pub key) based on the private key of the terminal device 1. This electronic signature proves that the creator of this transaction TxB is the terminal device 1.

FIG. 13 is a diagram showing the state after the transaction txB is transmitted from the terminal device 1. Transaction txB sent from the terminal device 1 is broadcast on the distributed DB network 3. In addition, the terminal device 1 uses a transaction ID (tx id) and an output index for specifying the output in the transaction txB specified by the transaction ID as specific information for specifying the authentication token sent to the authentication server device 2. (output index) is transmitted as shown in FIG. This allows the authentication server device 2 to specify the authentication UTXO associated with its own address.

FIG. 14 is a diagram showing the state after the transaction txB is transmitted from the terminal device 1. Transaction txB from the terminal device 1 shown in FIG. 13 is verified and approved by the distributed DB network 3 (S304). As a result, the authentication token, that is, the authentication UTXO is associated (moved) again with the address of the authentication server device 2 (B) on the distributed DB network 3. The UTXO for authentication corresponds to the output of transaction txB.

FIG. 15 is a diagram showing the flow of authentication tokens in the distributed DB network 3. As shown in FIG. 15, the authentication UTXO transaction associated with the address of the authentication server device 2 includes information on which output was used as input, so by tracing the transaction chain, it is possible to Confirmation processing can be performed depending on whether the UTXO is connected to the authentication UTXO sent by the authentication server device 2 itself.

In this way, the terminal device 1 does not need to input login information when receiving the authentication necessary to use the service. When the authentication server device 2 successfully authenticates the address of one terminal device 1, the service provider of the application program 1P may store the correspondence between the address and the user ID. In this case, each time the terminal device 1 becomes in a state where authentication is required while using a service based on the application program 1P, the processing unit 10 only needs to execute the processes from sending the authentication request in step S103 to step S109. Login information (user ID and password) is not required. Even if the correspondence between user ID and address is leaked at the service provider, it is extremely difficult to calculate the private key of the terminal device 1 from this information. As long as the keys are managed safely, risks can be reduced. This allows the service provider to perform user authentication without managing the user's confidential information. In addition, the information sent as a transaction from the terminal device 1 is not the private key itself but an electronic signature, and there is no need to enter the private key, reducing the possibility that the private key will be leaked to the outside. can.

The processing unit 10 may regenerate an address in step S102 based on the terminal device's own private key and perform authentication each time the application program 1P is started. In this case as well, steps S102 to S109 may be executed based on the secret key, and there is no need for the user to perform any input operations. Note that since the authentication token is not treated as an asset when performing authentication processing, even a private key may be generated each time authentication is required.

Further, as described in the first embodiment, the service provider only has to implement the application program 1P by incorporating the part that executes the above-mentioned processes (S101 to S109), and it is easy to introduce the authentication method. The authentication verification process is executed in the distributed DB network 3, and the movement of the authentication token is also automatically recorded. Service providers can incorporate this authentication method into their services at low cost.

Note that in the authentication method of the present disclosure, it is also possible to set a time limit for authentication. FIG. 16 is an explanatory diagram showing an example of the contents of a script including time limit settings. When the authentication server device 2 (B) creates the transaction txA for the terminal device 1 (A) in step S204, the authentication server device 2 (B) outputs the message that the terminal device 1 (A) is authenticated within a certain period of time as shown in FIG. If the authentication token is not returned, the authentication token can be collected using the user's own signature. The output of this transaction txA (authentication token) cannot be moved within a certain period of time without the signature script (A's signature, A's pub key, OP_TRUE) of terminal device 1 (A), but after a certain period of time becomes an authentication UTXO that can be operated by the signature script (B's signature, B's pub key, OP_FALSE) of the authentication server device 2 (B). Note that the script <num> in FIG. 16 is the length of the time limit, and [TIMEOUTTOP] is replaced with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY.

In the authentication method of the present disclosure, a one-time password can be added. FIG. 17 is an explanatory diagram showing an example of the contents of a one-time password script. When the authentication server device 2 (B) creates the transaction txA directed to the terminal device 1 (A) in step S204, as shown in FIG. Include the hash of the one-time password you shared with us. This results in an authentication UTXO that cannot be output unless the one-time password is also accurately included in the signature script on the terminal device 1 (A). Note that the script [HASHOP] in FIG. 17 is replaced with OP_HASH160 or OP_HASH256.

(Embodiment 2)
A more simplified authentication method can be realized using the distributed DB network 3. The configuration of the authentication system 100 in the second embodiment is the same as that in the first embodiment except that the details of the authentication method are different, that is, the hardware configurations of the terminal device 1, the authentication server device 2, and the distributed DB network 3 are different. Therefore, the same reference numerals are given to common configurations, and detailed explanations are omitted.

In the authentication method of the second embodiment, the authentication server device 2 can confirm that the terminal device 1 itself is the owner of the token in the distributed DB network 3 without performing the token delivery shown in the first embodiment. , authenticate it as legitimate. Authentication using the presence of a token in the distributed DB network 3 is possible in the same way without moving the token.

In the second embodiment, it is assumed that a transaction corresponding to the terminal device 1 is recorded in the distributed DB network 3 so that the terminal device 1 can prove that it is the owner of the token in the distributed DB network 3. As such, the following processing is performed. FIG. 18 is a sequence diagram illustrating an example of an authentication processing procedure in the second embodiment. Note that among the processing steps shown in the sequence diagram of FIG. 18, the steps that are common to the processing steps in the first embodiment shown in FIG. 5 are given the same step numbers and detailed explanations are omitted.

When the communication unit 22 of the authentication server device 2 receives an authentication request including the address of the terminal device 1 (S203), authentication processing is started. The processing unit 20 transmits specification information specifying arbitrary data (character string, document data, etc.) to the address of the terminal device 1 (step S214). In step S214, the processing unit 20 may transmit any data itself, but it only needs to be data that can be accessed in common by the authentication server device 2 and the terminal device 1, and information specifying this may be used. preferable.

In the terminal device 1, the communication unit 12 receives the designation information transmitted from the authentication server device 2, and the processing unit 10 specifies the designated data based on the designation information (step S114). The processing unit 10 creates an electronic signature for the identified data using its own private key (step S115), and transmits the created electronic signature to the authentication server device 2 (step S116).

In the authentication server device 2, when the communication unit 22 receives the electronic signature (S215), the processing unit 20 uses the address of the terminal device 1 to be authenticated, that is, the address included in the authentication request received in step S203. Public key information is derived (step S216). The processing unit 20 decrypts the electronic signature received in step S215 using the derived public key information, and performs verification such as comparing it with the hash value of the designated data (step S217).

In the second embodiment, the processing unit 20 further confirms that the token associated with the address of the terminal device 1 exists on the distributed DB network 3 (step S218). In the distributed DB network 3, the attribution of tokens, which are various digital assets, is made public in association with addresses, so it is sufficient to check this. The processing unit 20 transmits the authentication result based on whether or not confirmation has been achieved from the communication unit 22 to the terminal device 1 (S210), receives the authentication result at the terminal device 1 (S109), and ends the authentication process.

In this way, the authentication method using token attribution in the distributed DB network 3 can be simplified. If the attribution of some token can be confirmed through transaction processing based on private key information, and if data (electronic signature in the second embodiment) can be created based on the private key information, authentication can be performed as legitimate.

(Embodiment 3)
The configuration of the authentication system 100 in the third embodiment is the same as that in the first embodiment, except that the details of the authentication method are different, that is, the hardware configurations of the terminal device 1, the authentication server device 2, and the distributed DB network 3 are different. Therefore, the same components are given the same reference numerals and detailed explanations will be omitted.

In the authentication method of the third embodiment, similarly to the second embodiment, the authentication server device 2 performs authentication using the presence of the token in the distributed DB network 3 without transferring the token. However, the authentication server device 2 does not directly verify the information from the terminal device 1 that is the person to be authenticated, but the processing device 300 (node) in the distributed DB network 3 executes this verification.

3 is a functional block diagram showing the functions of a processing device 300 in Embodiment 3. FIG. In the third embodiment, part or all of the processing device 300 has a function (token contract). Furthermore, part or all of the processing device 300 functions as a specific node (authentication contract) that performs specific processing on information related to authentication, as a type of so-called smart contract. The specific process is verification of the electronic signature, as will be described later (see FIG. 19).

FIG. 19 is a sequence diagram illustrating an example of an authentication processing procedure in the third embodiment. Among the processing procedures shown in the sequence diagram of FIG. 19, the same steps as those in the second embodiment shown in FIG. 18 are given the same step numbers and detailed explanations will be omitted.

Regarding the terminal device 1, which is the person to be authenticated, before transmitting the authentication request (S103), the token transaction (which may be simply recorded) using its own address is sent to the distributed DB network 3 and recorded ( Step S131). The token may be digital information in the distributed DB network 3, and may be a token for authentication or a currency called virtual currency or crypto currency. The execution entity of step S131 does not have to be the terminal device 1 itself, which is the person to be authenticated. For example, if another terminal device 1 sends a transaction to the terminal device 1, which is the person to be authenticated, to attribute a token. Good too.

The authentication server device 2, which is the authenticator, receives the authentication request including the address of the terminal device 1 through the communication unit 22 (S203), and thereby starts the authentication process. When the authentication process is started, the processing unit 20 transmits arbitrary data (character string, document data, etc.) and the address of the terminal device 1, which is the person to be authenticated, to a specific node functioning as an authentication contract (step S221), The designation information is also transmitted to the address of the terminal device 1 (S214).

In the distributed DB network 3, the authentication contract receives the specification information and the address of the terminal device 1 sent from the authentication server device 2, and associates the data specified by the received specification information with the address of the terminal device 1. The information is recorded (written) in the distributed DB network 3 (step S311).

The processing unit 10 in the terminal device 1, which is the person to be authenticated, receives the designation information and specifies the designated data in the distributed DB network 3 (S114). The processing unit 10 creates an electronic signature using its own private key for the identified data (S115), and transmits the created electronic signature to the authentication contract of the distributed DB network 3 (Step S126). At this time, the electronic signature may correspond to other address information rather than the address information of the terminal device 1 included in the authentication request in step S103. However, the addresses (hash values) are based on the same private key information.

In the distributed DB network 3, the authentication contract receives the electronic signature transmitted from the terminal device 1 (step S312). As an authentication contract, the processing unit 30 of the processing device 300 obtains the address of the terminal device 1 as the electronic signature transmission source, which is registered in advance in the distributed DB network 3 (step S313). As an authentication contract, the processing unit 30 derives public key information of the terminal device 1 based on the acquired address (step S314). As an authentication contract, the processing unit 30 decrypts the electronic signature received in step S313 using the derived public key information, and performs verification such as comparing it with the hash value of specified data (step S315). If the verification is valid, the processing unit 30 records the verification result regarding the terminal device 1, which is the person to be authenticated, in the distributed DB network 3 (step S316). The determination result may be some kind of numerical value or logical value, such as a flag indicating whether it is valid or not.

In the authentication server device 2, at a predetermined timing after the processing unit 20 transmits the specified information (for example, after a certain period of time has elapsed or a notification from the person to be authenticated), the processing unit 20 associates the specified information with the address of the terminal device 1 received in step S203. It is confirmed that the issued token exists on the distributed DB network 3 (step S222). In the distributed DB network 3, the attribution of tokens, which are various digital assets, is made public in association with addresses, so it is sufficient to check this. The token transaction history for each address may be disclosed collectively in the token contract of the distributed DB network 3. The processing unit 20 further confirms that the verification result of the validity of the terminal device 1 in the distributed DB network 3 is recorded on the distributed DB network 3 (step S223). The processing unit 20 transmits the authentication result from the communication unit 22 to the terminal device 1 (S210) based on whether or not the confirmation in step S222 and step S223 was successful, and the terminal device 1 receives the authentication result ( S109), the authentication process ends.

In this way, the authentication server device 2 of the certifier does not have to directly exchange information such as electronic signatures and designated data with the terminal device 1 that is the person to be authenticated, and the verification of electronic signatures, etc. can also be distributed. It may also be done within the type DB network 3.

In Embodiments 1 to 3, it has been proven by transferring the token and sending and receiving electronic signatures that the identification information clearly linked to the token corresponds to the terminal device 1 or its user. Various other methods can be considered. For example, it is also possible to prove whether private key information is stored or not based on whether or not the same hash value can be derived. It does not matter if the information is digital or analog, as long as it can be created only when private key information is stored. It may be a keyword that can only be answered by the terminal device 1 or its user that stores private key information, it may be an image that only the terminal device 1 or its user can create, or it may be a question that only the terminal device 1 or its user can answer correctly. It may be. In addition, regarding the attribution corresponding to the address of the token in the distributed DB network 3, even if the attribution cannot be confirmed at the time of authentication, if it is confirmed that the attribution has occurred within a certain period of time in the past, If a token transfer transaction is confirmed a predetermined number of times or more, it may be determined that the transaction has been confirmed.

The disclosed embodiments should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is indicated by the claims rather than the above description, and it is intended that all changes within the meaning and range equivalent to the claims are included.

1 Terminal device (first device)
10 Processing unit 2 Authentication server device (second device)
20 Processing unit 3 Distributed DB network (distributed database network)
300 Processing device 30 Processing section

Claims (8)

In an authentication method in which authentication is performed between a first device related to a person to be authenticated and a second device related to a certifier,
It is composed of a plurality of processing nodes and storage media connected to each other via a network, and the plurality of processing nodes transfer addresses based on private key information to a predetermined type of digital asset that is transferable between addresses. A calculation is performed to verify and approve the transaction for recording the ownership of the token based on the electronic signature obtained from the private key information corresponding to the address of the ownership, and the results of the calculation are stored in a plurality of storage media. Using a blockchain system configured to hold information in a distributed manner,
When the first device transmits an authentication request to the second device,
The second device, which has received the authentication request, transmits specification information specifying arbitrary data to the first device,
The first device that has received the designation information creates data that is a calculation result based on the private key information of the first device for any data specified by the designation information, and transmits it to the second device;
The second device verifies the data and the attribution of the token to the address based on the private key information of the first device depending on whether it can be confirmed via the plurality of processing nodes of the blockchain system. , an authentication method for authenticating the first device. The authentication method according to claim 1 , wherein the token is transferred from another device other than the first device and the second device to the first device for a purpose other than authentication. The authentication method according to claim 1 , wherein the token is a non-cryptocurrency. The authentication method according to any one of claims 1 to 3 , wherein the attribution of the token is confirmed via a smart contract that discloses token transaction history for each address based on private key information of the first device. . The authentication method according to any one of claims 1 to 3 , wherein the second device imposes a time limit on data specified by the specification information. A specific node among the plurality of processing nodes receives an address designation based on private key information of the first device, and outputs a history of token transactions by the first device;
The authentication method according to any one of claims 1 to 3 , wherein the second device confirms the ownership of the token from the output token transaction history. The authentication method according to any one of claims 1 to 3 , wherein the data verification or the electronic signature verification is performed by an authentication contract implemented in the blockchain system. It is composed of a plurality of processing nodes and storage media connected to each other via a network, and the plurality of processing nodes transfer addresses based on private key information to a predetermined type of digital asset that is transferable between addresses. A calculation is performed to verify and approve the transaction for recording the ownership of the token based on the electronic signature obtained from the private key information corresponding to the address of the ownership, and the results of the calculation are stored in a plurality of storage media. a communication unit that sends and receives information to and from a blockchain system configured to hold information distributed in
Sends specification information specifying arbitrary data to the requesting device in response to the authentication request,
receiving from the request source data that is a calculation result at the request source based on private key information of the request source for arbitrary data specified by the specification information, and verifying the data;
The request source is authenticated based on the verification execution result and whether the attribution of the token to the address based on the private key information of the request source can be confirmed via the plurality of processing nodes of the blockchain system. An authentication device comprising an authentication section and.

Images