Authentication system, user terminal, authentication method and program

Abstract

To appropriately link distributed networks with each other while reducing a security risk.SOLUTION: An authentication system is configured to store: a URI of the first information and first designation information of designating a second wallet of a second distributed ledger shared by a plurality of second nodes accessible to second information relating to a user, in a first wallet of a first distributed ledger shared by a plurality of first nodes accessible to first information relating to the user; and a URI of second information and second designation information of designating the first wallet, in the second wallet. The first designation information and the second designation information are stored as non-fungible tokens. The second node in response to a request from a user terminal, uses the second designation information to request the first node to authenticate the second node for the user, and the first node in response to a request from a control part of the user terminal, uses the first designation information to request the second node to authenticate the first node for the user.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to an authentication system, a user terminal, an authentication method, and a program. [Background technology]

[0002] A centralized information management system has risks such as large-scale information leakage, function interruption due to failure of the core system, etc. As a technology to avoid such risks, a technology to manage information in a decentralized manner using a distributed network is known (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2020-507143 Summary of the Invention [Problem to be solved by the invention]

[0004] If a distributed network is simply applied to each existing information management system, the distributed network of each information management system will become siloed. Therefore, in order to improve user convenience, it is desirable to link distributed networks together and improve interoperability between each network. However, for example, sharing information about users between each network and increasing opportunities to exchange information about users between each network in order to link networks together poses a risk in terms of information leakage. Therefore, a technology that can appropriately link distributed networks together while reducing security risks has been desired. [Means for solving the problem]

[0005] The present disclosure can be realized in the following forms.

[0006] (1) According to one embodiment of the present disclosure, an authentication system is provided. The authentication system includes a first distributed network including a plurality of first nodes that share a first distributed ledger and have access to first information about a user, a second distributed network including a plurality of second nodes that share a second distributed ledger and have access to second information about the user, and a user terminal used by the user and having a user terminal control unit. The first node has a first control unit, and the second node has a second control unit. A first wallet in the first distributed ledger stores a URI of the first information and first designation information that designates a second wallet in the second distributed ledger, and the first designation information is stored as a first non-fungible token that is a token having non-fungibility. A second wallet in the second distributed ledger stores a URI of the second information and second designation information that designates the first wallet, and the second designation information is stored as a second non-fungible token that is a token having non-fungibility. The second control unit, in response to a first request from the user terminal control unit, requests the first node to perform first authentication to authenticate the second node for the user based on the first non-fungible token by specifying the first wallet using the second designation information. The first control unit, in response to a second request from the user terminal control unit, requests the second node to perform second authentication to authenticate the first node for the user based on the second non-fungible token by specifying the second wallet using the first designation information. According to this embodiment, authentication of the first node can be requested by specifying the second wallet using the first specification information, and authentication of the second node can be requested by specifying the first wallet using the second specification information. Therefore, when each node requests authentication, it is not necessary for each node to share the first information or the second information, or to exchange the first information or the second information between each node. Therefore, it is possible to reduce security risks when authentication of the first node or the second node is performed, and it is possible to appropriately cooperate with the first distributed network and the second distributed network. (2) In the above embodiment, the first distributed ledger and the second distributed ledger may each be configured by a blockchain, the storage of the URI of the first information in the first wallet and the storage of the first specified information may each be realized by a transaction stored in a block added to the first distributed ledger, and the recording of the URI of the second information in the second wallet and the recording of the second specified information may each be realized by a transaction stored in a block added to the second distributed ledger. According to this embodiment, the first distributed network and the second distributed network may each be configured as a blockchain network. This can further reduce the risk of centralized information management. (3) In the above embodiment, the first designation information may include a first identifier representing the second distributed network and a second identifier unique in the second distributed ledger, and designate the second wallet by a combination of the first identifier and the second identifier, the second designation information may include a third identifier representing the first distributed network and a fourth identifier unique in the first distributed ledger, and designate the first wallet by a combination of the third identifier and the fourth identifier, the second control unit may designate the first wallet by sending the third identifier to the first node in response to the first request, and the first control unit may designate the second wallet by sending the second identifier to the second node in response to the second request. According to this embodiment, authentication of each node can be easily requested by exchanging the second identifier and the fourth identifier between each node. (4) In the above embodiment, a first signed code, which is a first authentication code signed using a private key of the user terminal, is stored in the first wallet as the first non-fungible token, and a second signed code, which is a second authentication code corresponding to the first authentication code and signed using the private key, is stored in the second wallet as the second non-fungible token, and the second control unit transmits the second signed code to the first node when the first request is executed, and when the first authentication is requested, the first control unit determines whether the first signed code and the second signed code correspond to each other, and authenticates the second node when the first signed code and the second signed code correspond to each other. According to this embodiment, the second node can be easily authenticated by verifying the correspondence between the first signed code as the first non-fungible token and the second signed code as the second non-fungible token. (5) In the above embodiment, an expiration date may be set for the first signed code stored as the first non-fungible token, and when the first authentication is requested, the first control unit may determine whether the first signed code, the expiration date of which has not expired, corresponds to the second signed code. According to this embodiment, the second node can be authenticated when the expiration date of the first signed code has not expired, thereby further reducing security risks in the first authentication. (6) In the above embodiment, when the first control unit authenticates the second node, the first control unit may provide the first information to the second node and record information indicating that the first information has been provided to the second node in the first distributed ledger. This embodiment can improve the tamper resistance of the first distributed ledger. (7) In the above embodiment, the first information may be stored in a first database accessible from the first distributed network, the second information may be stored in a second database accessible from the second distributed network, and the first control unit may provide the second node with the first information acquired from the first database when authenticating the second node, and the second control unit may provide the first node with the second information acquired from the second database when authenticating the first node. According to this embodiment, security risks can be further reduced compared to, for example, a configuration in which the second node directly accesses the first information or a configuration in which the first node directly accesses the second information. (8) In the above embodiment, when the first request is executed, the second control unit may request the first authentication from the first node after a first local authentication of the user by the user terminal and a first public key authentication of the user terminal executed by the second control unit after the first local authentication are completed, and when the second request is executed, the first control unit may request the second node to perform the first authentication after a second local authentication of the user by the user terminal and a second public key authentication of the user terminal executed by the first control unit after the second local authentication are completed. According to this embodiment, when each node receives the first request or the second request from a user terminal, it can properly authenticate the user terminal using local authentication and public key authentication and then request authentication of each node.

[0007] The present disclosure may be realized in various forms other than an authentication system. For example, the present disclosure may be realized in the form of a user terminal or an authentication method. The present disclosure may also be realized in various forms, such as a distributed network system or a non-transitory tangible recording medium on which a computer program is recorded. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an authentication system in a first embodiment. [Diagram 2]FIG. 1 is a diagram illustrating a first distributed ledger. [Diagram 3] FIG. 1 is a diagram illustrating a second distributed ledger. [Figure 4] FIG. 11 is an explanatory diagram showing a pre-registration process. [Diagram 5] FIG. 11 is an explanatory diagram showing a linkage process. [Figure 6] FIG. 11 is a first diagram showing the first authentication process. [Figure 7] FIG. 2 is a second diagram showing the first authentication process. [Figure 8] FIG. 11 is a first diagram showing the second authentication process. [Figure 9] FIG. 2 is a second diagram illustrating the second authentication process. [Figure 10] FIG. 11 is an explanatory diagram showing an authentication system according to a second embodiment. [Figure 11] FIG. 13 is an explanatory diagram showing an authentication system according to a third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] A. First embodiment: 1 is an explanatory diagram showing an authentication system 10 in this embodiment. The authentication system 10 includes a first network system 100, a second network system 200, and a user terminal 400. The network systems, and each network system and the user terminal 400, are configured to be able to communicate with each other via the Internet INT.

[0010] The first network system 100 includes a first distributed network 101 including a plurality of first nodes 110. The first nodes 110 are connected to each other by P2P (Peer to Peer). In this embodiment, the first network system 100 further includes a first database 190 accessible from the first distributed network 101. The first network system 100 is configured as a management system that manages personal numbers assigned to individuals for the provision of public services. A network system including a distributed network is also called a distributed network system.

[0011] Each first node 110 is configured to be able to access first information inf1 related to a user who uses the user terminal 400. In this embodiment, the first information inf1 is a personal number given to the user and is stored in the first database 190.

[0012] Each first node 110 shares a first distributed ledger DL1. In this embodiment, the first distributed ledger DL1 is configured by a blockchain. As a result, the first distributed network 101 is configured as a blockchain network. The blockchain that configures the distributed ledger may be, for example, a public type or a private type. In addition, for example, some of the multiple nodes that configure the blockchain network may not be full nodes, and may be lightweight nodes.

[0013] The first node 110 includes a first control unit 111. The first control unit 111 is configured by a computer including a CPU, a storage unit, and an input / output interface for inputting and outputting signals from and to the outside. The storage unit included in the first control unit 111 stores the first distributed ledger DL1. In addition, the CPU included in the first control unit 111 executes a program stored in the storage unit, thereby causing the first control unit 111 to realize various functions, such as a function for executing a transaction in the first distributed ledger DL1 and a function for requesting second authentication, which will be described later.

[0014] The second network system 200 includes a second distributed network 201 configured with a plurality of second nodes 210. The second nodes 210 are connected to each other by P2P. In this embodiment, the second network system 200 further includes a second database 290 accessible from the second distributed network 201. The second network system 200 is configured as a management system for managing personal medical data.

[0015] Each second node 210 is configured to be able to access second information inf2 relating to the user. In this embodiment, the second information inf2 is a management ID for managing the medical data of the user, and is stored in the second database 290.

[0016] The second distributed ledger DL2 is shared by each second node 210. In this embodiment, the second distributed ledger DL2 is configured by a blockchain, similar to the first distributed ledger DL1.

[0017] The second node 210 includes a second control unit 211. The second control unit 211 is configured by a computer like the first control unit 111, and includes a CPU, a storage unit, and an input / output interface. The storage unit included in the second control unit 211 stores the second distributed ledger DL2. In addition, the CPU included in the second control unit 211 executes a program stored in the storage unit, thereby causing the second control unit 211 to realize various functions, such as a function of executing a transaction in the second distributed ledger DL2 and a function of requesting first authentication, which will be described later.

[0018] The user terminal 400 is used by a user. The user terminal 400 includes a user terminal control unit 401 and a display unit 410. The user terminal control unit 401 is configured by a computer similar to the first control unit 111, and includes a CPU, a storage unit 403, and an input / output interface. The CPU included in the first control unit 111 executes a program 404 stored in the storage unit 403, thereby causing the user terminal control unit 401 to realize various functions, such as a function to execute a first request and a function to execute a second request, which will be described later. The program 404 may be, for example, a dedicated application program usable by the user terminal control unit 401, or a function extension program that extends the functions of a general-purpose application (for example, a web browser) usable by the user terminal control unit 401. The display unit 410 is configured as a touch-operable liquid crystal display, and also serves as an input unit and an operation unit.

[0019] FIG. 2 is a diagram illustrating the first distributed ledger DL1. The first distributed ledger DL1 has a first wallet W1. The first wallet W1 is specified in the first distributed ledger DL1 by a first wallet address WA1 that is unique in the first distributed ledger DL1. In this embodiment, the first wallet W1 is configured to be able to store each data for each hierarchical level in the first wallet W1. For example, URI (Uniform Resource Identifier) ​​data, designated information data, signature data, public key data, provided information data, etc. can be stored in each hierarchical level in the first wallet W1. For example, the URI of the first information inf1 is stored as the URI data directly under the first wallet W1, and the first public key OK1 is stored as the public key data. In the hierarchical level IDa1 in the first wallet W1, the first designated information sp1 that designates the second wallet W2 of the second distributed ledger DL2 is stored as the designated information data, and the signed code cc31s is stored as the signature data.

[0020] The first designation information sp1 is stored in the first wallet W1 as a first non-fungible token T1, which is a token having non-fungibility. A non-fungible token means that it is a unique token that cannot be substituted, unlike fungible tokens such as so-called crypto assets (also called virtual currencies). The first designation information sp1 is stored as an NFT (non-fungible token) that complies with token standards such as ERC-721, ERC-1155, and ERC-4907. In this embodiment, the signed code cc31s is also stored in the first wallet W1 as the first non-fungible token T1, similar to the first designation information sp1.

[0021] FIG. 2 shows transaction data TD1 representing a transaction executed in the first distributed ledger DL1. In this embodiment, the storage of information in the first wallet W1 described above is realized by executing a transaction in the first distributed ledger DL1. Each transaction included in the transaction data TD1 is stored in a block added to the first distributed ledger DL1 configured by a blockchain. Note that in FIG. 2, each data in the first wallet W1 is shown separately from the transaction data TD1 to facilitate understanding of the technology, but each data in the first wallet W1 in this embodiment is actually realized by the transaction data TD1.

[0022] In each transaction included in the transaction data TD1, storage destination information indicating the storage destination of the information by the transaction, and stored data information indicating the data stored in the storage destination and the attributes of the data are described. The storage destination information is configured to be able to describe information further specifying a hierarchy in the storage destination wallet in addition to a wallet address specifying the storage destination wallet. The stored data information is expressed in the format of "attribute:data" in FIG. 2. For example, in transaction TX12, the first wallet address WA1 specifying the first wallet W1 and the hierarchy IDa1 of the first wallet W1 are described as the storage destination information, and the signed code cc1s, which is the signature data, is described as the data information. When transaction TX12 is executed, the signed code cc1s is stored as the signature data in the first wallet W1 specified by the first wallet address WA1. Note that information specifying the hierarchy of the storage destination is not described in transaction TX11. In this embodiment, when a transaction in which the hierarchy of the storage destination is not described is executed, the data described in the data information of the transaction is stored directly under the wallet specified by the wallet address.

[0023] FIG. 3 is a diagram illustrating the second distributed ledger DL2. The second distributed ledger DL2 has a second wallet W2. The second wallet W2 is specified in the second distributed ledger DL2 by a second wallet address WA2 that is unique in the second distributed ledger DL2. In this embodiment, the second wallet W2 is configured to be able to store each data for each hierarchy in the second wallet W2, similar to the first wallet W1. For example, in the hierarchy IDb1 in the second wallet W2, the URI of the second information inf2 is stored as the URI data, the second designation information sp2 is stored as the designation information data, the signed code cc32s is stored as the signature data, and the second public key OK2 is stored as the public key data. The second designation information sp2 is stored in the second wallet W2 as the second non-fungible token T2, which is a token having non-fungibility, similar to the first designation information sp1. In this embodiment, the signed code cc32s is also stored in the second wallet W2 as the second non-fungible token T2.

[0024] 3 shows transaction data TD2 representing a transaction executed in the second distributed ledger DL2. Storage of information in the second wallet W2 is realized by executing a transaction in the second distributed ledger DL2. Each transaction included in the transaction data TD2 is stored in a block added to the second distributed ledger DL2. In this embodiment, each data in the second wallet W2 is realized by the transaction data TD2, similar to the first wallet W1. Each transaction included in the transaction data TD2 describes storage destination information and stored data information, similar to the transaction data TD1.

[0025] In this embodiment, the first designation information sp1 and the second designation information sp2 are represented by a multi-layer registration data structure. More specifically, the first designation information sp1 includes a first identifier representing the second distributed network 201 and a second identifier unique in the second distributed ledger DL2. The first designation information sp1 designates the second wallet W2 by a combination of the first identifier and the second identifier. In FIG. 2, the first designation information sp1 is represented in the format of "first identifier: second identifier". In this embodiment, the first identifier is the URN (Uniform Resource Name) of the second distributed network 201, and is represented as "NT2" in FIG. 2. The second identifier is the second wallet address WA2. Similarly, the second designation information sp2 shown in FIG. 3 includes a third identifier representing the first distributed network 101 and a fourth identifier unique in the first distributed ledger DL1. In FIG. 3, the second designation information sp2 is represented in the format of "third identifier: fourth identifier". The second designation information sp2 designates the second wallet W2 by a combination of the third identifier and the fourth identifier. In this embodiment, the third identifier is the URN of the first distributed network 101, and is represented as "NT1" in Fig. 3. The fourth identifier is the first wallet address WA1.

[0026] FIG. 4 is an explanatory diagram showing a pre-registration process. FIG. 5 is an explanatory diagram showing a linking process. The linking process refers to a process of storing the first designation information sp1 in the first wallet W1 and storing the second designation information sp2 in the second wallet W2. The pre-registration process refers to a process of storing the first information inf1 in the first wallet W1 prior to the linking process. By executing the first linking process, the first distributed network 101 and the second distributed network 201 are in a linked state. When two networks are in a linked state, the nodes constituting each network can request node authentication from each other. Node authentication refers to a case where a control unit of a node constituting one network requests authentication of its own node to a node constituting the other network on behalf of a user, using the designation information stored in its own storage unit, in response to a request from the user terminal control unit 401.

[0027] More specifically, for example, when the first distributed network 101 and the second distributed network 201 are in a linked state, the second control unit 211 is able to request the first authentication from the first control unit 111 using the second designation information sp2 in response to the first request from the user terminal control unit 401, and the first control unit 111 is able to request the second authentication from the second control unit 211 using the first designation information sp1 in response to the second request from the user terminal control unit 401. The first authentication refers to the first node 110 authenticating the second node 210 for the user based on the first non-fungible token T1. The second authentication refers to the second node 210 authenticating the first node 110 for the user based on the second non-fungible token T2. ​​In this embodiment, the first request and the first authentication are performed in a first authentication process described later. The second request and the second authentication are performed in a second authentication process described later.

[0028] 4 is executed when, prior to the linking process, for example, a predetermined start operation is performed by the user in the user terminal 400. In step S102, the user terminal control unit 401 executes a pre-registration request to the first node 110. In step S102 in this embodiment, the user terminal control unit 401 transmits to the first node 110 a predetermined request message and identification information for the first node 110 to identify the first information inf1 on the first database 190. This identification information is stored in, for example, an IC card or the like so as to be readable by the user terminal 400.

[0029] When a pre-registration request is executed, the first control unit 111 executes user authentication using local authentication and public key authentication in steps S104 to S112. More specifically, the first control unit 111 authenticates the user by FIDO (Fast IDentity Online) authentication in steps S104 to S112. In step S104, the first control unit 111 returns a challenge code cc1 to the user terminal 400.

[0030] In step S106, the user terminal control unit 401 that has received the challenge code cc1 executes local authentication of the user. As the local authentication, face authentication using a camera provided in the user terminal 400, biometric authentication such as fingerprint authentication using a fingerprint reader, authentication using a PIN (Personal Identification Number), pattern authentication, etc. can be used. If the local authentication fails, the user terminal control unit 401 executes a predetermined error process. In this case, the user terminal control unit 401 may notify the user of the error via the display unit 410 or a speaker, and may execute the local authentication again, or may end the pre-registration process when the local authentication fails a predetermined number of times. If the local authentication is successful, in step S108, the user terminal control unit 401 generates a first secret key PK1 and a first public key OK1 that pairs with the first secret key PK1. For example, RSA encryption or elliptic curve encryption is used to generate the first secret key PK1 and the first public key OK1. Hereinafter, the first secret key PK1 will also be referred to simply as the secret key, and the first public key OK1 will also be referred to simply as the public key.

[0031] In step S110, the user terminal control unit 401 digitally signs the challenge code cc1 using the first private key PK1. The challenge code cc1 signed using the first private key PK1 is also called the signed code cc1s. The user terminal control unit 401 then returns the signed code cc1s and the first public key OK1 to the first node 110.

[0032] In step S112, the first control unit 111 verifies the signature of the signed code cc1s using the first public key OK1. If the signature verification fails, the first control unit 111 executes a predetermined error process. In this case, the first control unit 111 notifies the user terminal 400 of the error, for example. If the signature verification is successful, in step S114, the first control unit 111 executes a transaction in the first distributed ledger DL1 to store the URI of the first information inf1 and the first public key OK1 in the first wallet W1 specified by the first wallet address WA1. The first wallet address WA1 is irreversibly generated from the first public key OK1 prior to step S116. Therefore, the first wallet address WA1 is paired with the first private key PK1, similar to the first public key OK1.

[0033] More specifically, in step S116 in this embodiment, the transaction TX11 shown in FIG. 2 is executed. In the transaction TX11, the first wallet address WA1 is described as the storage destination information, and the URI of the first information inf1, which is URI data, and the first public key OK1, which is public key data, are described as the storage data information. The URI of the first information inf1 is obtained from the first database 190 by the first control unit 111, for example, based on the identification information received in step S104. "Executing a transaction in a distributed ledger" refers to generating a transaction by a node having a distributed ledger and propagating the transaction to other nodes sharing the distributed ledger. This updates the distributed ledger. More specifically, in this embodiment, the transaction generated in the distributed ledger configured by the blockchain is propagated to each node sharing the distributed ledger and verified. If the verification is successful, the transaction is stored in a block to be added to the distributed ledger. Examples of blockchain consensus algorithms include PoW (Proof of Work), PoS (Proof of Stake), and PoI (Proof of Importance).

[0034] In step S116, first control unit 111 returns first wallet address WA1 to user terminal 400. In step S118, user terminal control unit 401 stores first wallet address WA1 and first private key PK1 in memory unit 403. After step S118, user terminal control unit 401 also uses first wallet address WA1 as a path indicating the location of data in memory unit 403.

[0035] The linking process shown in FIG. 5 is executed when, for example, a predetermined start operation is performed by the user in the user terminal 400 after the pre-registration process is completed. In step S202, the user terminal control unit 401 executes a first linking request to the second node 210. In step S202, the user terminal control unit 401 transmits a predetermined request message to the second node 210 and designates a linking destination that desires to link with the second distributed network 201. In this embodiment, the user terminal control unit 401 designates the first distributed network 101 as a linking destination by, for example, transmitting the URI of the first distributed network 101 to the second node 210. When the first linking request is executed, the second control unit 211 returns a challenge code cc2 to the user terminal 400 in step S204.

[0036] The user terminal control unit 401 that has received the challenge code cc2 generates the second information inf2 in step S206. The second information inf2 is generated, for example, based on the user's email address. Next, in step S208, the user terminal control unit 401 generates a second secret key PK2 and a second public key OK2 that pairs with the second secret key PK2 in the same manner as in step S108 of FIG. 4. In step S210, the user terminal control unit 401 digitally signs the challenge code cc2 using the second secret key PK2. The challenge code cc2 that has been signed using the second secret key PK2 is also called a signed code cc2s. After that, the user terminal control unit 401 returns the first wallet address WA1, the second information inf2, the signed code cc2s, and the second public key OK2 to the second node 210.

[0037] In step S212, the second control unit 211 verifies the signature of the signed code cc2s using the second public key OK2, similar to step S112 in Fig. 4. If the signature verification is successful, in step S214, the second control unit 211 executes a second cooperation request to the first node 110. In step S214, the second control unit 211 specifies the first wallet address WA1 as the destination, and transmits a predetermined request message to the first node 110.

[0038] When the second link request is executed, in step S216, the first control unit 111 transmits the challenge code cc31 to the user terminal 400 by specifying the first wallet address WA1 as the destination, and returns the challenge code cc32 corresponding to the challenge code cc31 to the second node 210. In this embodiment, the challenge code cc31 and the challenge code cc32 are the same code. The challenge code cc31 is also referred to as the first authentication code, and the challenge code cc32 is also referred to as the second authentication code.

[0039] In step S218, the second control unit 211 receives the challenge code cc32 and transmits the challenge code cc32 to the user terminal 400, specifying the first wallet address WA1 as the transmission destination.

[0040] The user terminal control unit 401 that has received both challenge codes performs local authentication of the user in step S220, similar to step S106 in FIG. 4. If the local authentication is successful, in step S222, the user terminal control unit 401 digitally signs the challenge code cc31 and the challenge code cc32 using the first private key PK1. The challenge code cc31 signed with the first private key PK1 is also called the signed code cc31s or the first signed code. The challenge code cc32 signed with the first private key PK1 is also called the signed code cc32s or the second signed code. Thereafter, the user terminal control unit 401 returns the signed code cc31s to the first node 110, and returns the signed code cc32s to the second node 210.

[0041] In step S224, the first control unit 111 verifies the signature of the signed code cc31s using the first public key OK1, similarly to step S112 in Fig. 4. If the signature verification is successful, in step S226, the first control unit 111 executes a transaction in the first distributed ledger DL1 to store the signed code cc31s verified using the first public key OK1 in the first wallet W1 as the first non-fungible token T1. In step S226 in this embodiment, the transaction TX12 shown in Fig. 2 is executed. In this embodiment, an expiration date is set for the signed code cc31s.

[0042] The second control unit 211, which has received the signed code cc32s from the user terminal control unit 401, designates the first wallet address WA1 as the destination in step S228 and transmits the signed code cc32s and the second wallet address WA2 to the first node 110. The second wallet address WA2 is, for example, irreversibly generated from the second public key OK2 in step S228.

[0043] In step S230, the first control unit 111 determines whether the signed code cc31s corresponds to the signed code cc32s. In step S230, the first control unit 111 may directly verify the correspondence between the signed codes, or may verify the correspondence between the challenge codes after decrypting each signed code to a challenge code by the first public key OK1. If the first control unit 111 determines that the signed code cc31s does not correspond to the signed code cc32s, it executes a predetermined error process. In this case, the first control unit 111 notifies, for example, the second node 210 or the user terminal 400 that the authentication has failed. If the first control unit 111 determines that the signed code cc31s corresponds to the signed code cc32s, in step S232, it executes a transaction in the first distributed ledger DL1 to store the first specified information sp1 as specified information data in the hierarchical IDa1 of the first wallet W1. The first designation information sp1 is stored as the first non-fungible token T1. In step S232 in this embodiment, the transaction TX13 shown in FIG. 2 is executed. In the transaction TX13, the first wallet address WA1 and the hierarchical IDa1 are described as the storage destination information, and the first designation information sp1, which is the designation information data, is described as the stored data information. In step S234, the first control unit 111 transmits a verification success notification to the second node 210, which indicates that the signature verification has been successful.

[0044] In step S236, the second control unit 211 that has received the verification success notification executes a transaction in the second distributed ledger DL2 to store the URI of the second information inf2, the second public key OK2, the second designation information sp2, and the signed code cc32s in the second wallet W2. In step S236 in this embodiment, the transaction TX21 shown in FIG. 3 is executed. In the transaction TX21, the second wallet address WA2 and the hierarchical IDb1 of the second wallet W2 are described as storage destination information, and the URI of the second information inf2, which is URI data, the second public key OK2, which is public key data, the second designation information sp2, which is designation information data, and the signed code cc32s, which is signature data, are described as stored data information. In this embodiment, the second information inf2, the second public key OK2, the second designation information sp2, and the signed code cc32s are stored as the second non-fungible token T2.

[0045] In step S238, second control unit 211 transmits second wallet address WA2 to user terminal 400. In step S240, user terminal control unit 401 stores second wallet address WA2 and second private key PK2 in memory unit 403. After step S240, user terminal control unit 401 also uses second wallet address WA2 as a path indicating the location of data in memory unit 403.

[0046] FIG. 6 is a first diagram showing the first authentication process. FIG. 7 is a second diagram explaining the first authentication process. The first authentication process shown in FIG. 6 and FIG. 7 is executed when, for example, a predetermined start operation is performed by the user in the user terminal 400 after the completion of the linking process shown in FIG. 5. For example, the user starts the first authentication process in order to have the second control unit 211 acquire the first information inf1 after the completion of the first authentication process. In step S302, the user terminal control unit 401 executes a first request to the second node 210. In step S302, the user terminal control unit 401, for example, specifies the second wallet address WA2 as the destination and transmits a predetermined request message to the second node 210. When the first request is executed, the second control unit 211 returns a challenge code cc4 to the user terminal 400 in step S304.

[0047] In steps S306 to S310, the second control unit 211 authenticates the user by FIDO authentication. In step S306, the user terminal control unit 401 that has received the challenge code cc4 executes local authentication of the user, similar to step S106 in Fig. 4. The local authentication of the user by the user terminal 400 that is executed after the first request is executed, as in step S306, is also referred to as first local authentication.

[0048] If the first local authentication is successful, in step S308, the user terminal control unit 401 signs the challenge code cc4 using the second private key PK2. The challenge code cc4 signed using the second private key PK2 is also called the signed code cc4s. Then, the user terminal control unit 401 returns the signed code cc4s to the second node 210. In step S310, the second control unit 211 that has received the signed code cc4s verifies the signature of the signed code cc4s using the second public key OK2, similar to step S212 in FIG. 5. The public key authentication of the user terminal 400 performed by the second control unit 211 after the first local authentication as in step S310 is also called the first public key authentication.

[0049] If the signature verification is successful, in step S312, the second control unit 211 requests the first node 110 to perform the first authentication by specifying the first wallet W1 using the second specification information sp2. More specifically, in step S314, the second control unit 211 requests the first node 110 to perform the first authentication by transmitting the first wallet address WA1, which is the third identifier, as a header. In this manner, in this embodiment, the request for the first authentication is requested after the FIDO authentication by the first local authentication and the first public key authentication is completed. Also, in step S314 in this embodiment, the second control unit 211 further transmits the signed code cc32s stored in the second wallet W2 to the first node 110.

[0050] The first control unit 111, which has received the first wallet address WA1 and the signed code cc32s, verifies in step S314 whether the transmitted signed code cc32s corresponds to the signed code cc31s stored in the first wallet W1 as the first non-fungible token T1, in the same manner as in step S234 of FIG. 5. More specifically, in step S314 in this embodiment, the first control unit 111 verifies whether the signed code cc31s whose validity has not expired corresponds to the signed code cc32s. If the validity of the signed code cc31s has expired, the first control unit 111 determines that the signed code cc31s does not correspond to the signed code cc32s. If the first control unit 111 determines that the two codes correspond to each other, it authenticates the second node 210, and notifies the second node 210 of the success of the first authentication in step S316. In step S318, the second control unit 211 notifies the user terminal 400 that the first authentication has been successful.

[0051] Fig. 7 shows the first authentication process when the verification of the signed code fails in step S316 in Fig. 6. In step S320, the first control unit 111 transmits the challenge code cc51 to the user terminal 400 by specifying the first wallet address WA1 as the destination, and returns the challenge code cc52 corresponding to the challenge code cc51 to the second node 210. In this embodiment, the challenge code cc51 and the challenge code cc52 are the same code. In step S322, the second node 210 transmits the challenge code cc52 to the user terminal 400 by specifying the first wallet address WA1 as the destination.

[0052] In step S324, the user terminal control unit 401 executes local authentication of the user, similar to step S220 in Fig. 5. If the local authentication is successful, in step S326, the user terminal control unit 401 digitally signs the challenge code cc51 and the challenge code cc52 using the first private key PK1 that pairs with the specified first wallet address WA1. Then, the user terminal control unit 401 returns a signed code cc51s, which is the challenge code cc51 signed with the first private key PK1, to the first node 110, and returns a signed code cc52s, which is the challenge code cc52 signed with the first private key PK1, to the second node 210.

[0053] In step S328, the first control unit 111 verifies the signature of the signed code cc51s, similar to step S224 in Fig. 5. If the signature verification is successful, in step S330, the first control unit 111 stores the signed code cc51s as a third non-fungible token T3 having non-fungibility in the first wallet W1, similar to step S226 in Fig. 5. In step S330 in this embodiment, the transaction TX14 shown in Fig. 2 is executed. In the transaction TX14, the first wallet address WA1 and the hierarchical IDa2 are described as the storage destination information, and the signed code cc51s, which is the signature data, is described as the stored data information. In this embodiment, an expiration date is set for the signed code cc51s.

[0054] In step S332, the second control unit 211 transmits the signed code cc52s and the second wallet address WA2 to the first node 110, similar to step S228 in FIG. 5. In step S334, the first control unit 111 determines whether the signed code cc51s and the signed code cc52s correspond to each other, similar to step S230 in FIG. 5. If the first control unit 111 determines that the two codes correspond to each other, in step S336, the first designation information sp1, which is the designation information data, is stored as the third non-fungible token T3 in the hierarchical IDa2 of the first wallet W1, similar to step S232 in FIG. 5. In step S336 in this embodiment, the transaction TX15 shown in FIG. 2 is executed. In the transaction TX15, the first wallet address WA1 and the hierarchical IDa2 are described as the storage destination information, and the first designation information sp1, which is the designation information data, is described as the stored data information. Furthermore, if the first control unit 111 determines that the two codes correspond to each other, it authenticates the second node 210, and in step S338 notifies the second node 210 that the authentication has been successful.

[0055] In step S340, the second control unit 211 stores the second designation information sp2 and the signed code cc52s in the second wallet W2, similarly to step S236 in FIG. 2. In step S340 in this embodiment, the transaction TX22 shown in FIG. 3 is executed. In the transaction TX22, the second wallet address WA2 and the hierarchical IDb2 are described as the storage destination information, and the second designation information sp2, which is the designation information data, and the signed code cc52s, which is the signature data, are described as the stored data information. The second designation information sp2 and the signed code cc52s are stored as a fourth non-fungible token T4 having non-fungibility. Step S342 is similar to step S318 in FIG. 6.

[0056] FIG. 8 is a first diagram showing the second authentication process. FIG. 9 is a second diagram explaining the second authentication process. The second authentication process is substantially the same as the process in which the first node 110 and the second node 210 are interchanged in the first authentication process. More specifically, steps S402 to S442 in FIG. 8 and FIG. 9 correspond to steps S302 to S342 in FIG. 6 and FIG. 7, respectively. The second authentication process is executed when, for example, a predetermined start operation is performed by the user in the user terminal 400 after the linking process shown in FIG. 5 is completed. For example, the user starts the second authentication process in order to have the first control unit 111 acquire the second information inf2 after the second authentication process is completed.

[0057] First, in step S402, the user terminal 400 executes a second request to the first node 110. In step S404, the first control unit 111 returns a challenge code cc6 to the user terminal 400.

[0058] In steps S406 to S410, the first control unit 111 authenticates the user by FIDO authentication. The user terminal control unit 401, which has received the challenge code cc6, executes the second local authentication in step S406. The second local authentication refers to local authentication of the user by the user terminal 400, which is executed when the second request is executed. If the second local authentication is successful, in step S408, the user terminal control unit 401 signs the challenge code cc6 using the first private key PK1. The challenge code cc6 signed using the first private key PK1 is also called the signed code cc6s. Then, the user terminal control unit 401 returns the signed code cc6s to the first node 110. In step S410, the first control unit 111, which has received the signed code cc6s, verifies the signature of the signed code cc6s using the first public key OK1. The public key authentication of the user terminal 400 executed by the first control unit 111 after the second local authentication, as in step S410, is also called second public key authentication.

[0059] In step S412, the first control unit 111 requests the second node 210 to perform the second authentication by specifying the second wallet W2 using the first specification information sp1. More specifically, the first control unit 111 requests the second node 210 to perform the second authentication by transmitting the second wallet address WA2, which is the second identifier, as a header. In this manner, in this embodiment, the request for the second authentication is requested after the FIDO authentication by the second local authentication and the second public key authentication is completed. In addition, in step S412 in this embodiment, the first control unit 111 further transmits the signed code cc31s stored in the first wallet W1 to the second node 210.

[0060] If the second authentication is requested, the second control unit 211 verifies the correspondence between the signed codes in step S414. If the signed codes correspond to each other, the second control unit 211 transmits an authentication success notification to the first node 110 in step S416. Thereafter, the first control unit 111 notifies the user terminal 400 that the second authentication has been successful in step S418.

[0061] Fig. 9 shows the second authentication process when the verification of the signed code fails in step S414 in Fig. 8. In step S420, the second control unit 211 transmits the challenge code cc71 to the user terminal 400 by specifying the second wallet address WA2 as the destination, and returns the challenge code cc72 corresponding to the challenge code cc71 to the first node 110. In this embodiment, the challenge code cc71 and the challenge code cc72 are the same code. In step S422, the first node 110 transmits the challenge code cc72 to the user terminal 400 by specifying the second wallet address WA2 as the destination.

[0062] In step S424, the user terminal control unit 401 executes local authentication of the user. If the local authentication is successful, in step S426, the user terminal control unit 401 digitally signs the challenge code cc71 and the challenge code cc72 using the second private key PK2 paired with the specified second wallet address WA2. Then, the user terminal control unit 401 returns a signed code cc71s representing the challenge code cc71 signed with the second private key PK2 to the second node 210, and returns a signed code cc72s representing the challenge code cc72 signed with the second private key PK2 to the first node 110.

[0063] In step S428, the second control unit 211 verifies the signature of the signed code cc71s using the second public key OK2. If the signature verification is successful, in step S430, the second control unit 211 stores the signed code cc71s in the second wallet W2 as a fifth non-fungible token T5 having non-fungibility. In step S430, the transaction TX23 shown in FIG. 3 is executed. In the transaction TX23, the second wallet address WA2 and the hierarchy Idb3 are described as the storage destination information, and the signed code cc71s, which is the signature data, is described as the stored data information. The signed code cc71s stored as the fifth non-fungible token T5 may have an expiration date set.

[0064] In step S432, the first control unit 111 transmits the signed code cc72s and the first wallet address WA1 to the second node 210. In step S434, the second control unit 211 judges whether the signed code cc71s and the signed code cc72s correspond to each other. If the second control unit 211 judges that the two codes correspond to each other, in step S436, the second designation information sp2, which is the designation information data, is stored in the second wallet W2 as the fifth non-fungible token T5. In step S430, the transaction TX24 shown in FIG. 3 is executed. In the transaction TX24, the second wallet address WA2 and the hierarchical Idb3 are described as the storage destination information, and the second designation information sp2, which is the designation information data, is described as the storage data information. In addition, if the second control unit 211 judges that the two codes correspond to each other, it authenticates the first node 110 and notifies the first node 110 of the success of the authentication in step S438.

[0065] In step S440, the first control unit 111 stores the first designation information sp1 and the signed code cc72s as the sixth non-fungible token T6 having non-fungibility in the first wallet W1. In step S432, the transaction TX16 shown in FIG. 2 is executed. In the transaction TX16, the first wallet address WA1 and the hierarchical ID a3 are described as the storage destination information, and the first designation information sp1, which is the designation information data, is described as the stored data information. Step S442 is the same as step S418 in FIG. 8.

[0066] The authentication method of this embodiment is realized by executing the steps of the advance registration process, the linking process, the first authentication process, and the second authentication process described above.

[0067] In this embodiment, when the first control unit 111 authenticates the second node 210 in the first authentication, it provides the first information inf1 to the second node 210. In this case, the first control unit 111 provides the first information inf1 acquired from the first database 190 to the second node 210. Similarly, when the second control unit 211 authenticates the first node 110 in the second authentication, it provides the second information inf2 acquired from the second database 290 to the first node 110. In FIG. 1, an example of an acquisition path of the second information inf2 by the first control unit 111 and an example of an acquisition path of the first information inf1 by the second control unit 211 are shown by dashed lines. Note that, prior to providing the first information inf1 and the second information inf2, for example, verification of the correspondence of the signed code may be performed again.

[0068] When the first control unit 111 provides the first information inf1 to the second node 210, the first control unit 111 records, in the first distributed ledger DL1, first provision information indicating that the first information inf1 has been provided to the second node 210. Similarly, the second control unit 211 records, in the second distributed ledger DL2, second provision information indicating that the second information inf2 has been provided to the first node 110. In this embodiment, the first provision information and the second provision information are recorded by executing a transaction in each distributed ledger to be stored in a block to be added to each distributed ledger. FIG. 2 shows, as an example of such a transaction, a transaction TX17 in which the first wallet address WA1 and the hierarchical ID a4 are described as storage destination information, and the first provision information PR1, which is provision information data, is described as storage data information. Each provision information may be represented, for example, by the URI of the first information inf1 or the second information inf2, and the first designation information sp1 or the second designation information sp2.

[0069] According to the authentication system 10 in the present embodiment described above, the URI of the first information inf1 and the first designation information sp1 as the first non-fungible token T1 are stored in the first wallet W1, and the URI of the second information inf2 and the second designation information sp2 as the second non-fungible token T2 are stored in the second wallet W2. The second control unit 211 requests the first authentication by designating the first wallet W1 using the second designation information sp2 in response to the first request. The first control unit 111 requests the second authentication by designating the second wallet W2 using the first designation information sp1 in response to the second request. This allows the first node 110 to request authentication by using the first designation information sp1, and the second node 210 to request authentication by using the second designation information sp2. Therefore, when each node requests authentication, it is not necessary for each node to share the first information inf1 or the second information inf2, or for each node to exchange the first information inf1 or the second information inf2. Therefore, security risks when authentication of the first node 110 or the second node 210 is performed can be reduced, and the first distributed network 101 and the second distributed network 201 can work together appropriately.

[0070] Also, for example, when the first distributed network 101 and the second distributed network 201 are linked by a link application such as a decentralized exchange (DEX), the DEX or the like may be a security weakness. In this embodiment, since the DEX or the like is not required, such security risks can be suppressed. Also, when the first distributed network 101 and the second distributed network 201 are linked via a distributed network for linking, it is usually required that the specifications of the first distributed network 101 and the second distributed network 201 are adapted to the specifications of the distributed network for linking. The distributed network for linking configured as a blockchain network is also called a relay chain. In this embodiment, since the relay chain or the like is not required, the first distributed network 101 and the second distributed network 201 can be easily linked.

[0071] In this embodiment, the first distributed ledger DL1 and the second distributed ledger DL2 are each configured by a blockchain, and the storage of the first information inf1 and the storage of the first specified information sp1 in the first wallet W1 are each realized by a transaction stored in a block added to the first distributed ledger DL1, and the storage of the second information inf2 and the storage of the second specified information sp2 in the second wallet W2 are each realized by a transaction stored in a block added to the second distributed ledger DL2. This allows the first distributed network 101 and the second distributed network 201 to be configured as a blockchain network. This further reduces the risk of centralized information management.

[0072] In this embodiment, the first designation information sp1 designates the second wallet W2 by a combination of the first identifier and the second identifier, and the second designation information sp2 designates the first wallet W1 by a combination of the third identifier and the fourth identifier. The second control unit 211 designates the first wallet W1 by transmitting the third identifier to the first node 110 in response to the first request. The first control unit 111 designates the second wallet W2 by transmitting the first identifier to the second node 210 in response to the second request. Therefore, the first authentication or the second authentication can be easily requested by exchanging the second identifier or the fourth identifier between the nodes. In particular, if the first identifier or the third identifier, or information corresponding to the first identifier or the third identifier, is not exchanged between the nodes when requesting the first authentication or the second authentication, the possibility that the third party will read the authentication request destination can be reduced even if the first authentication request or the second authentication request is intercepted by a third party. Therefore, the security risk can be further reduced.

[0073] In this embodiment, the first wallet W1 stores the first signed code as the first non-fungible token T1, and the second wallet W2 stores the second signed code as the second non-fungible token T2. ​​When the second control unit 211 receives the first request, it transmits the second signed code to the first node 110. In the first authentication, the first control unit 111 determines whether the first signed code and the second signed code correspond to each other, and authenticates the second node 210 if the two codes correspond to each other. Therefore, the second node 210 can be easily authenticated by verifying the correspondence between the first signed code as the first non-fungible token T1 and the second signed code as the second non-fungible token T2.

[0074] In this embodiment, an expiration date is set for the first signed code stored as the first non-fungible token T1, and the first control unit 111 determines whether the first signed code, whose expiration date has not yet expired, corresponds to the second signed code in the first authentication. Therefore, the second node 210 can be authenticated when the expiration date of the first signed code has not yet expired, so that security risks in the first authentication can be further suppressed.

[0075] Furthermore, in this embodiment, when the first control unit 111 authenticates the second node 210, it provides the first information inf1 to the second node 210 and records the first provided information in the first distributed ledger DL1. This can improve the tamper resistance of the first distributed ledger DL1.

[0076] Furthermore, in this embodiment, when the first control unit 111 authenticates the second node 210, it provides the second node 210 with the first information inf1 acquired from the first database 190, and when the second control unit 211 authenticates the first node 110, it provides the first node 110 with the second information inf2 acquired from the second database 290. Therefore, security risks can be further suppressed compared to, for example, a form in which the second node 210 directly accesses the first information inf1 or a form in which the first node 110 directly accesses the second information inf2.

[0077] Furthermore, in this embodiment, when a first request is executed, the second control unit 211 requests the first node 110 to perform the first authentication after the first local authentication and the first public key authentication are completed. When a second request is executed, the first control unit 111 requests the second node 210 to perform the second authentication after the second local authentication and the second public key authentication are completed. Therefore, when each node receives the first request or the second request from the user terminal 400, it can appropriately authenticate the user terminal 400 using local authentication and public key authentication and then request authentication of each node.

[0078] B. Second embodiment: 10 is an explanatory diagram showing an authentication system 10b in the second embodiment. Unlike the first embodiment, the authentication system 10b includes a third network system 300. Parts of the configuration of the authentication system 10b that are not particularly described are similar to those of the first embodiment.

[0079] The third network system 300 includes a third distributed network 301 configured by a plurality of third nodes 310. The third distributed network 301 is connected to the Internet INT, similar to other networks and the user terminal 400 in the authentication system 10b. The third node 310 is configured to be able to access third information inf3 about users stored in a third database 390 accessible from the third distributed network 301. Each third node 310 shares a third distributed ledger configured by a blockchain. The third node 310 includes a third control unit 311 configured by a computer similar to the first control unit 111.

[0080] In this embodiment, in addition to the second designation information sp2, the second wallet W2 stores the third designation information sp3 designating the third wallet W3 of the third distributed ledger as the seventh non-fungible token T7 having non-fungibility. The third designation information sp3 is represented by a multi-level registration type data structure, for example, similar to the first designation information sp1 and the second designation information sp2. The third wallet W3 stores the URI of the third information inf3 and the first designation information sp1. In the third wallet W3, the first designation information sp1 is stored as the eighth non-fungible token T8 having non-fungibility. As a result, in this embodiment, the second distributed network 201 and the third distributed network 301 are in a linked state, similar to the first distributed network 101 and the second distributed network 201 being in a linked state. The cooperation between the second distributed network 201 and the third distributed network 301 is realized, for example, by a process similar to the cooperation process of FIG. 5 being executed between the user terminal 400, the second node 210, and the third node 310.

[0081] In the authentication system 10b, the third designation information sp3 is not stored in the first wallet W1, but the first control unit 111 can acquire the third information inf3 via the second node 210. In more detail, for example, the first control unit 111 causes the second node 210 to authenticate the first node 110 using the first designation information sp1, and then causes the second control unit 211 to request the third node 310 to authenticate the second node 210 using the third designation information sp3 stored in the second wallet W2. The authentication of the second node 210 by the third node 310 is realized, for example, by a process similar to the first authentication process shown in FIG. 6 and FIG. 7 being executed between the user terminal 400, the second node 210, and the third node 310. When the second node 210 is authenticated by the third node 310, the second control unit 211 acquires, for example, the third information inf3 from the third node 310. This allows the first control unit 111 to obtain the third information inf3 obtained by the second control unit 211. Similarly to the above, the third control unit 311 may obtain the first information inf1 via the second node 210. In this case, authentication of the third node 310 by the second node 210 is realized by, for example, executing a process similar to the second authentication process shown in Fig. 8 and Fig. 9 between the user terminal 400, the second node 210, and the third node 310.

[0082] In this way, the first distributed network 101 and the third distributed network 301 can be linked while reducing the amount of data stored in the first wallet W1 and the third wallet W3. Furthermore, the fact that the first wallet W1 and the third wallet W3 are associated cannot be read from the information stored in the first wallet W1, so security risks can be further reduced. In other embodiments, the authentication system 10b may include, for example, four or more distributed networks.

[0083] C. Third embodiment: 11 is an explanatory diagram showing an authentication system 10c in the third embodiment. Unlike the first embodiment, the authentication system 10c includes a fourth network system 500. Parts of the configuration of the authentication system 10c that are not particularly described are similar to those of the first embodiment.

[0084] The fourth network system 500 includes a non-distributed network 501. The network 501 is configured with a plurality of nodes Nd including a terminal device 510. The network 501 is connected to the Internet INT, as well as other networks in the authentication system 10c and the user terminal 400. In this embodiment, the fourth network system 500 is configured as a centralized network in a medical institution.

[0085] The terminal device 510 includes a fourth control unit 511. The fourth control unit 511 is configured by a computer like the first control unit 111, and includes a CPU, a storage unit 512, and an input / output interface. The terminal device 510 is configured to be able to access fourth information inf4 related to a user who uses the user terminal 400. In this embodiment, the fourth information inf4 is an ID given to the user as an identification number of a patient at a medical institution, and is stored in a database DB in the storage unit 512.

[0086] In this embodiment, the database DB in the storage unit 512 stores the URI of the fourth information inf4 and the first designation information sp1 with the address Ad unique in the database DB as the primary key. In addition to the second designation information sp2, the second wallet W2 stores the fourth designation information sp4 as a ninth non-fungible token T9 having non-fungibility. The fourth designation information sp4 designates a record in the database DB with the address Ad as the primary key by combining the fifth identifier representing the terminal device 510 and a sixth identifier unique in the database DB. The fourth designation information sp4 is expressed in the format of "fifth identifier:sixth identifier" in FIG. 11. In this embodiment, the fifth identifier is the URN of the terminal device 510, and is expressed as "TE" in FIG. 3. The sixth identifier is the address Ad.

[0087] In this embodiment, the network 501 and the second distributed network 201 are in a linked state because the fourth designation information sp4 is stored in the second wallet W2 and the first designation information sp1 is stored in the database DB with the address Ad as a primary key as described above. The link between the network 501 and the second distributed network 201 is realized, for example, by executing a process similar to the link process of FIG. 5 between the user terminal 400, the second node 210, and the terminal device 510. In this case, in the process corresponding to step S228 of FIG. 5, the fourth control unit 511 transmits the signed challenge code and the address Ad to the second node 210. In addition, in the process corresponding to step S236, the fourth control unit 511 stores the URI of the fourth information inf4 and the first designation information sp1 in the storage unit 512 with the address Ad as a primary key.

[0088] In this embodiment, the fourth control unit 511 can use the first designation information sp1 to request the second node 210 to authenticate the terminal device 510 based on the ninth non-fungible token T9 in response to a request from the user terminal control unit 401. The authentication of the terminal device 510 by the second node 210 is realized by, for example, executing a process similar to the first authentication process shown in FIG. 6 and FIG. 7 between the user terminal 400, the second node 210, and the terminal device 510. This allows the fourth control unit 511 to obtain, for example, the second information inf2 from the second node 210. Similarly, the second control unit 211 can use the fourth designation information sp4 to request the terminal device 510 to authenticate the second node 210 based on the first designation information sp1 stored with the address Ad as a primary key. In this case, authentication of the second node 210 by the terminal device 510 is realized by, for example, executing a process similar to the second authentication process shown in Fig. 8 and Fig. 9 between the user terminal 400, the second node 210, and the terminal device 510. Also, the fourth control unit 511 may acquire the first information inf1 via the second node 210, for example, as described in the third embodiment. Similarly, the first control unit 111 may acquire the fourth information inf4 via the second node 210.

[0089] In other embodiments, for example, the first distributed network 101 may be in a cooperative state with a non-distributed network, or one distributed network may be in a cooperative state with two or more non-distributed networks.

[0090] D. Other embodiments: (D1) In the above embodiment, the first network system 100 is configured as a management system for personal numbers, and the second network system 200 is configured as a management system for medical data. In contrast, each network system may not be configured in this way. For example, the first network system 100 may be configured as a management system for medical data, and the second network system 200 may be configured as a management system for personal numbers. In addition, each network system may be configured as another system, such as a system for managing financial data. In addition, each network system may be configured as a system for providing a virtual space service, such as a so-called metaverse. In this case, the first information inf1 and the second information inf2 may be data representing items owned by a user in a virtual space, for example.

[0091] (D2) In the above embodiment, the first distributed ledger DL1 and the second distributed ledger DL2 are configured using a blockchain. In contrast, the first distributed ledger DL1 and the second distributed ledger DL2 do not have to be configured using a blockchain, and may be configured using a distributed ledger of another type. In this case, the first distributed ledger DL1 and the second distributed ledger DL2 may be configured using a directed acyclic graph, a hash graph, a holochain, or the like.

[0092] (D3) In the above embodiment, the first designation information sp1 includes the first identifier and the second identifier, but may not include the first identifier and the second identifier. For example, the first designation information sp1 may be represented by an identifier that uniquely represents the "distributed ledger wallet" itself. Similarly, the second designation information sp2 may not include the third identifier and the fourth identifier.

[0093] (D4) In the above embodiment, the first control unit 111 determines whether the first signed code and the second signed code correspond to each other in the first authentication, and authenticates the second node 210 if the two codes correspond to each other. In contrast, the first control unit 111 may not authenticate the second node 210 in this way in the first authentication, and may, for example, verify whether the second wallet address WA2 transmitted from the second control unit 211 corresponds to the first designation information sp1 stored in the first wallet W1 as the first non-fungible token T1, and authenticate the second node 210 if they correspond to each other. Similarly, the second control unit 211 may not determine whether the first signed code and the second signed code correspond to each other in the second authentication.

[0094] (D5) In the above embodiment, an expiration date may be set for the second signed code stored as the second non-fungible token T2 and the signed code cc52s stored as the fourth non-fungible token T4. Also, an expiration date may not be set for the first signed code stored as the first non-fungible token T1 and the signed code cc51s stored as the third non-fungible token T3. In this case, an expiration date may simply not be set for each signed code. Also, for example, in step S232 of FIG. 5, a null value may be stored as signature data in the hierarchical IDa1 of the first wallet W1. In this case, the null value signature data is described as stored data information in the transaction TX12. As a result, in the first authentication process of FIG. 6, since the signed code does not correspond in step S316, the first node 110 can authenticate the second node 210 after the signature verification using the new challenge code shown in FIG. 7. Therefore, the security risk in the first authentication can be further reduced. Similarly, for example, a null value may be stored as signature data in hierarchical IDa2 of first wallet W1 in step S340 in FIG.

[0095] (D6) In the above embodiment, the first control unit 111 records the first provision information PR1 in the first distributed ledger DL1, but the first provision information PR1 does not have to be recorded. Similarly, the second control unit 211 does not have to record the second provision information in the second distributed ledger DL2.

[0096] (D7) In the above embodiment, when the first control unit 111 authenticates the second node 210, it provides the second node 210 with the first information inf1 acquired from the first database 190. In response to this, the first control unit 111 may not provide the first information inf1 in this manner. For example, when the first control unit 111 authenticates the second node 210, it may permit the second node 210 to access the first information inf1 on the first database 190. This access permission may be temporary. Similarly, when the second control unit 211 authenticates the first node 110, it may not provide the first node 110 with the second information inf2 acquired from the second database 290.

[0097] (D8) In the above embodiment, the first control unit 111 and the second control unit 211 request the second authentication or the first authentication after the FIDO authentication is completed, but the FIDO authentication does not have to be executed. For example, the first control unit 111 and the second control unit 211 may request the second authentication or the first authentication after authenticating the user terminal control unit 401 by password authentication. [Explanation of symbols]

[0098] 10, 10b, 10c... authentication system, 100... first network system, 101... first distributed network, 110... first node, 111... first control unit, 190... first database, 200... second network system, 201... second distributed network, 210... second node, 211... second control unit, 290... second database, 300... third network system, 301... third distributed network, 310... third node, 311... third control unit, 390... third database, 400... user terminal, 401... user terminal control unit, 403... memory unit, 404... program, 410... display unit, 500... fourth network system, 501... network, 510... terminal device, 511... fourth control unit, 512... memory unit

Claims

1. a first decentralized network including a first node having a first distributed ledger; a second distributed network including a second node having a second distributed ledger; the first node has a first control unit; the second node has a second control unit, First designation information designating a second wallet of the second distributed ledger is stored in a first wallet of the first distributed ledger, and the first designation information is stored as a first non-fungible token that is a token having non-fungibility; second designation information designating the first wallet is stored in the second wallet of the second distributed ledger, and the second designation information is stored as a second non-fungible token that is a token having non-fungibility; the second control unit requests the first node to perform first authentication to authenticate the second node based on the first non-fungible token by specifying the first wallet using the second specification information; An authentication system in which the first control unit requests the second node to perform second authentication to authenticate the first node based on the second non-fungible token by specifying the second wallet using the first specification information.

2. A user terminal used by a user, A user terminal control unit is provided, The user terminal control unit configured to execute a second request to a first node in a first decentralized network having a first distributed ledger; configured to execute the first request to a second node in a second distributed network, the second node having a second distributed ledger; First designation information designating a second wallet of the second distributed ledger is stored in a first wallet of the first distributed ledger, and the first designation information is stored as a first non-fungible token that is a token having non-fungibility; second designation information designating the first wallet is stored in the second wallet of the second distributed ledger, and the second designation information is stored as a second non-fungible token that is a token having non-fungibility; When the first request is executed, a second control unit of the second node requests the first node to perform first authentication to authenticate the second node based on the first non-fungible token by specifying the first wallet using the second specification information; When the second request is executed, a first control unit of the first node requests the second node to perform second authentication to authenticate the first node based on the second non-fungible token by specifying the second wallet using the first specification information; The user terminal control unit performing a first local authentication of the user by the user terminal in response to a response from the second node to the first request; performing a second local authentication of the user by the user terminal in response to a response from the first node to the second request; the second control unit performs first public key authentication of the user terminal after the first local authentication, and requests the first authentication from the first node after the first public key authentication is completed; The first control unit performs second public key authentication of the user terminal after the second local authentication, and requests the second authentication from the second node after the second public key authentication is completed.

3. A process in which a first node belonging to a first distributed network and having a first distributed ledger requests a second node belonging to a second distributed network and having a second distributed ledger to authenticate the first node based on a second non-fungible token stored in a first wallet of the first distributed ledger by specifying the second wallet using first designation information stored as a first non-fungible token in the first wallet of the first distributed ledger, the first designation information specifying a second wallet of the second distributed ledger; and a step of requesting the first node to authenticate the second node based on the first non-fungible token by the second node specifying the first wallet using second designation information stored in the second wallet as the second non-fungible token, the second designation information specifying the first wallet.

4. A program executed by a computer that controls a user terminal used by a user, The computer, executing a second request to a first node in the first decentralized network and having the first distributed ledger; and executing a first request to a second node that belongs to a second distributed network and has a second distributed ledger; First designation information designating a second wallet of the second distributed ledger is stored in a first wallet of the first distributed ledger, and the first designation information is stored as a first non-fungible token that is a token having non-fungibility; second designation information designating the first wallet is stored in the second wallet of the second distributed ledger, and the second designation information is stored as a second non-fungible token that is a token having non-fungibility; When the first request is executed, a second control unit of the second node requests the first node to perform first authentication to authenticate the second node based on the first non-fungible token by specifying the first wallet using the second specification information. When the second request is executed, a first control unit of the first node requests the second node to perform second authentication to authenticate the first node based on the second non-fungible token by specifying the second wallet using the first specification information.

Images