WO2024070315A1 - 認証システム、ユーザ端末、認証方法、および、プログラム - Google Patents

認証システム、ユーザ端末、認証方法、および、プログラム Download PDF

Info

Publication number
WO2024070315A1
WO2024070315A1 PCT/JP2023/029831 JP2023029831W WO2024070315A1 WO 2024070315 A1 WO2024070315 A1 WO 2024070315A1 JP 2023029831 W JP2023029831 W JP 2023029831W WO 2024070315 A1 WO2024070315 A1 WO 2024070315A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
information
control unit
wallet
authentication
Prior art date
Application number
PCT/JP2023/029831
Other languages
English (en)
French (fr)
Inventor
剛明 牧野
Original Assignee
株式会社Ｉｄホールディングス
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Ｉｄホールディングス filed Critical 株式会社Ｉｄホールディングス
Publication of WO2024070315A1 publication Critical patent/WO2024070315A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • This disclosure relates to an authentication system, a user terminal, an authentication method, and a program.
  • Centralized information management systems carry risks such as large-scale information leaks and outages due to failures in core systems.
  • One known technology for avoiding such risks is to manage information in a decentralized manner using a distributed network (for example, see Patent Document 1).
  • an 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
  • 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 a first authentication for authenticating 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 a second authentication for authenticating the first node for the user based on the second non-fungible token by specifying the second wallet using the first designation information.
  • the authentication of the first node can be requested by specifying the second wallet using the first specification information
  • the 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 the 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.
  • 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
  • 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.
  • the first distributed network and the second distributed network may each be configured as a blockchain network. Therefore, the risk due to centralized information management can be further reduced.
  • 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
  • the first control unit may designate the second wallet by sending the second identifier to the second node in response to the second request.
  • authentication of each node can be easily requested by exchanging the second identifier and the fourth identifier between each node.
  • a first signed code that 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
  • a second signed code that is a second authentication code that is signed using the private key and corresponds to the first authentication code is stored in the second wallet as the second non-fungible token
  • 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.
  • 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.
  • 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.
  • 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.
  • the first control unit 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. According to this embodiment, it is possible to improve the tamper resistance of the first distributed ledger.
  • the first information may be stored in a first database that can be referenced from the first distributed network
  • the second information may be stored in a second database that can be referenced from the second distributed network
  • security risks can be further reduced compared to, for example, an aspect in which the second node directly accesses the first information or an aspect in which the first node directly accesses the second information.
  • 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.
  • each node receives the first request or the second request from a user terminal, it is possible to appropriately authenticate the user terminal using local authentication and public key authentication and then request authentication of each node.
  • the present disclosure can also be realized in various forms other than an authentication system.
  • it can be realized in the form of a user terminal or an authentication method.
  • the present disclosure can 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.
  • FIG. 1 is an explanatory diagram showing an authentication system according to a first embodiment.
  • FIG. 1 is a diagram illustrating a first distributed ledger.
  • FIG. 1 is a diagram illustrating a second distributed ledger.
  • FIG. 11 is an explanatory diagram showing a pre-registration process.
  • FIG. 11 is an explanatory diagram showing a linkage process.
  • FIG. 11 is a first diagram showing a first authentication process.
  • FIG. 2 is a second diagram showing the first authentication process.
  • FIG. 11 is a first diagram showing the second authentication process.
  • FIG. 11 is a second diagram illustrating the second authentication process.
  • FIG. 11 is an explanatory diagram showing an authentication system according to a second embodiment.
  • FIG. 13 is an explanatory diagram showing an authentication system according to a third embodiment.
  • 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 are configured to be able to communicate with each other, and each network system and the user terminal 400 are configured to be able to communicate with each other via the Internet INT.
  • the first network system 100 comprises a first distributed network 101 composed of a plurality of first nodes 110. Each of the first nodes 110 is connected to each other by P2P (Peer to Peer). In this embodiment, the first network system 100 further comprises 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 that comprises a distributed network is also called a distributed network system.
  • Each first node 110 is configured to be able to access first information inf1 related to the user who uses the user terminal 400.
  • the first information inf1 is a personal number assigned to the user, and is stored in the first database 190.
  • Each first node 110 shares a first distributed ledger DL1.
  • the first distributed ledger DL1 is configured by a blockchain.
  • 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. Also, for example, some of the multiple nodes that configure the blockchain network may not be full nodes, and may be lightweight nodes.
  • 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.
  • 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 transactions in the first distributed ledger DL1 and a function for requesting second authentication, which will be described later.
  • 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 via P2P.
  • 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.
  • Each second node 210 is configured to be able to access second information inf2 related to the user.
  • the second information inf2 is a management ID for managing the user's medical data, and is stored in the second database 290.
  • Each second node 210 shares the second distributed ledger DL2.
  • the second distributed ledger DL2 is configured using a blockchain, just like the first distributed ledger DL1.
  • the second node 210 includes a second control unit 211.
  • the second control unit 211 is configured by a computer, similar to 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.
  • 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 to execute transactions in the second distributed ledger DL2 and a function to request the first authentication described below.
  • 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 like 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 described below and a function to execute a second request.
  • the program 404 may be, for example, a dedicated application program that can be used by the user terminal control unit 401, or a function extension program that extends the functions of a general-purpose application (e.g., a web browser) that can be used 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.
  • 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.
  • the first wallet W1 is configured to be able to store each data for each hierarchy in the first wallet W1.
  • URI Uniform Resource Identifier
  • the URI of the first information inf1 is stored as URI data directly below the first wallet W1
  • the first public key OK1 is stored as public key data.
  • the first specified information sp1 that specifies the second wallet W2 of the second distributed ledger DL2 is stored as specified information data
  • the signed code cc31s is stored as signature data.
  • the first designation information sp1 is stored in the first wallet W1 as the first non-fungible token T1, which is a token that has non-fungibility.
  • a non-fungible token 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.
  • 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.
  • FIG. 2 shows transaction data TD1 representing a transaction executed in the first distributed ledger DL1.
  • 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 that is added to the first distributed ledger DL1 configured by a blockchain.
  • each piece of data in the first wallet W1 is shown separately from the transaction data TD1 to make the technology easier to understand, but in this embodiment, each piece of data in the first wallet W1 is actually realized by the transaction data TD1.
  • Each transaction included in the transaction data TD1 includes storage destination information indicating the storage destination of the information from the transaction, and stored data information indicating the data to be stored in the storage destination and the attributes of the data.
  • the storage destination information is configured to be able to include information specifying the hierarchy within the storage destination wallet in addition to the 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 ID a1 of the first wallet W1 are described as storage destination information, and the signed code cc1s, which is the signature data, is described as data information.
  • transaction TX12 When transaction TX12 is executed, the signed code cc1s is stored as signature data in the first wallet W1 specified by the first wallet address WA1.
  • transaction TX11 does not include information specifying the hierarchy of the storage destination.
  • the data described in the data information of the transaction is stored directly under the wallet specified by the wallet address.
  • 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.
  • 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.
  • 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
  • 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 a second non-fungible token T2, which is a token having non-fungibility, similar to the first designation information sp1.
  • the signed code cc32s is also stored in the second wallet W2 as the second non-fungible token T2.
  • FIG. 3 shows transaction data TD2 representing a transaction executed in the second distributed ledger DL2.
  • Storing information in the second wallet W2 is achieved by executing a transaction in the second distributed ledger DL2.
  • Each transaction included in the transaction data TD2 is stored in a block that is added to the second distributed ledger DL2.
  • each piece of 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 includes storage destination information and stored data information, similar to the transaction data TD1.
  • the first designation information sp1 and the second designation information sp2 are represented by a multi-level 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 specifies 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.
  • URN Uniform Resource Name
  • 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.
  • the second designation information sp2 is expressed 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.
  • the third identifier is the URN of the first decentralized network 101, and is represented as "NT1" in FIG. 3.
  • the fourth identifier is the first wallet address WA1.
  • FIG. 4 is an explanatory diagram showing the pre-registration process.
  • FIG. 5 is an explanatory diagram showing the 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.
  • Node authentication refers to the control unit of a node constituting one network requesting authentication of its own node to a node constituting the other network on behalf of the user, using the designation information stored in its own memory unit, in response to a request from the user terminal control unit 401.
  • the second control unit 211 can request the first authentication from the first control unit 111 using the second specification information sp2 in response to the first request from the user terminal control unit 401, and the first control unit 111 can request the second authentication from the second control unit 211 using the first specification 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.
  • the first request and the first authentication are performed in the first authentication process described later.
  • the second request and the second authentication are performed in the second authentication process described later.
  • the pre-registration process shown in FIG. 4 is executed, prior to the linking process, when, for example, a predetermined start operation is performed by the user on the user terminal 400.
  • the user terminal control unit 401 executes a pre-registration request to the first node 110.
  • 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, for example, on an IC card or the like so as to be readable by the user terminal 400.
  • the first control unit 111 When a pre-registration request is executed, the first control unit 111 performs user authentication using local authentication and public key authentication in steps S104 to S112. More specifically, the first control unit 111 authenticates the user using 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.
  • FIDO Fast IDentity Online
  • step S106 the user terminal control unit 401 that has received the challenge code cc1 performs local authentication of the user.
  • the local authentication biometric authentication such as face authentication using a camera provided in the user terminal 400, 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 performs a predetermined error process. In this case, the user terminal control unit 401 may notify the user of the error via, for example, the display unit 410 or a speaker, and may perform local authentication again, or may end the pre-registration process if the local authentication fails a predetermined number of times.
  • step S108 the user terminal control unit 401 generates a first private key PK1 and a first public key OK1 that is paired with the first private key PK1.
  • a first private key PK1 For example, RSA cryptography or elliptic curve cryptography is used to generate the first private key PK1 and the first public key OK1.
  • the first private key PK1 will also be referred to simply as the private key
  • the first public key OK1 will also be referred to simply as the public key.
  • step S110 the user terminal control unit 401 digitally signs the challenge code cc1 using the first private key PK1.
  • the challenge code cc1 that has been 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.
  • 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, just like the first public key OK1.
  • step S116 in this embodiment the transaction TX11 shown in FIG. 2 is executed.
  • the first wallet address WA1 is described as the storage destination information
  • the URI of the first information inf1 which is URI data
  • the first public key OK1 which is public key data
  • 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 that share the distributed ledger. This updates the distributed ledger.
  • the transaction generated in the distributed ledger configured by the blockchain is propagated to each node that shares the distributed ledger and verified. If the verification is successful, the transaction is stored in a block that is added to the distributed ledger.
  • Examples of blockchain consensus algorithms include PoW (Proof of Work), PoS (Proof of Stake), and PoI (Proof of Importance).
  • step S116 the first control unit 111 returns the first wallet address WA1 to the user terminal 400.
  • step S118 the user terminal control unit 401 stores the first wallet address WA1 and the first private key PK1 in the memory unit 403. After step S118, the user terminal control unit 401 also uses the first wallet address WA1 as a path representing the location of data in the memory unit 403.
  • the linking process shown in FIG. 5 is executed when, for example, a predetermined start operation is performed by the user on the user terminal 400 after the pre-registration process is completed.
  • the user terminal control unit 401 executes a first linking request to the second node 210.
  • the user terminal control unit 401 transmits a predetermined request message to the second node 210 and specifies a linking destination that desires to link with the second distributed network 201.
  • the user terminal control unit 401 transmits, for example, the URI of the first distributed network 101 to the second node 210, thereby specifying the first distributed network 101 as the linking destination.
  • the second control unit 211 returns a challenge code cc2 to the user terminal 400 in step S204.
  • the user terminal control unit 401 which 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.
  • step S208 the user terminal control unit 401 generates the second secret key PK2 and the second public key OK2 that pairs with the second secret key PK2 in a manner similar to that of step S108 in FIG. 4.
  • 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 the signed code cc2s.
  • the user terminal control unit 401 then 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.
  • step S212 the second control unit 211 uses the second public key OK2 to verify the signature of the signed code cc2s, similar to step S112 in FIG. 4. If the signature verification is successful, in step S214, the second control unit 211 executes a second coordination 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.
  • step S216 the first control unit 111 sends challenge code cc31 to the user terminal 400 by specifying the first wallet address WA1 as the destination, and returns challenge code cc32 corresponding to challenge code cc31 to the second node 210.
  • challenge code cc31 and challenge code cc32 are the same code.
  • Challenge code cc31 is also referred to as the first authentication code
  • challenge code cc32 is also referred to as the second authentication code.
  • step S218 the second control unit 211 receives the challenge code cc32 and sends the challenge code cc32 to the user terminal 400, specifying the first wallet address WA1 as the destination.
  • the user terminal control unit 401 which 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.
  • the user terminal control unit 401 then returns the signed code cc31s to the first node 110, and returns the signed code cc32s to the second node 210.
  • step S224 the first control unit 111 verifies the signature of the signed code cc31s using the first public key OK1, similar 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.
  • the second control unit 211 which receives the signed code cc32s from the user terminal control unit 401, in step S228 specifies the first wallet address WA1 as the destination 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.
  • step S230 the first control unit 111 determines whether the signed code cc31s corresponds to the signed code cc32s.
  • the first control unit 111 may, for example, 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 using 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 authentication has failed.
  • 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 ID a1 of the first wallet W1.
  • the first specification information sp1 is stored as the first non-fungible token T1.
  • the transaction TX13 shown in FIG. 2 is executed.
  • the first wallet address WA1 and hierarchical ID a1 are described as storage destination information
  • the first specification information sp1, which is specification information data is described as stored data information.
  • the first control unit 111 transmits a verification success notification to the second node 210, indicating that the signature verification was successful.
  • step S236 the second control unit 211, which has received the successful verification 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 specification information sp2, and the signed code cc32s in the second wallet W2.
  • step S236 in this embodiment the transaction TX21 shown in FIG. 3 is executed.
  • 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 specification information sp2, which is specification information data, and the signed code cc32s, which is signature data, are described as stored data information.
  • the second information inf2, the second public key OK2, the second specification information sp2, and the signed code cc32s are stored as a second non-fungible token T2.
  • step S2308 the second control unit 211 transmits the second wallet address WA2 to the user terminal 400.
  • step S240 the user terminal control unit 401 stores the second wallet address WA2 and the second private key PK2 in the memory unit 403. After step S240, the user terminal control unit 401 also uses the second wallet address WA2 as a path representing the location of data in the memory unit 403.
  • 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.
  • the user starts the first authentication process to have the second control unit 211 acquire the first information inf1 after the completion of the first authentication process.
  • the user terminal control unit 401 executes a first request to the second node 210.
  • 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.
  • the second control unit 211 returns a challenge code cc4 to the user terminal 400 in step S304.
  • the second control unit 211 authenticates the user through FIDO authentication in steps S306 to S310.
  • the user terminal control unit 401 which receives the challenge code cc4, performs local authentication of the user in step S306, similar to step S106 in FIG. 4.
  • the local authentication of the user by the user terminal 400 that is performed after the first request is executed, as in step S306, is also called the first local authentication.
  • 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.
  • the user terminal control unit 401 then returns the signed code cc4s to the second node 210.
  • 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.
  • the second control unit 211 requests the first authentication from the first node 110 by specifying the first wallet W1 using the second specification information sp2. More specifically, in step S314, the second control unit 211 specifies the first wallet W1 by sending the first wallet address WA1, which is the third identifier, as a header to the first node 110. Thus, in this embodiment, the request for the first authentication is requested after the FIDO authentication based on 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 sends the signed code cc32s stored in the second wallet W2 to the first node 110.
  • 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 expiration date has not yet expired, corresponds to the signed code cc32s. If the expiration date 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.
  • the first control unit 111 determines that the two codes correspond, it authenticates the second node 210 and notifies the second node 210 in step S316 that the first authentication was successful. In step S318, the second control unit 211 notifies the user terminal 400 that the first authentication was successful.
  • FIG. 7 shows the first authentication process when verification of the signed code fails in step S316 in FIG. 6.
  • the first control unit 111 designates the first wallet address WA1 as the destination and transmits challenge code cc51 to the user terminal 400, and returns challenge code cc52 corresponding to challenge code cc51 to the second node 210.
  • challenge code cc51 and challenge code cc52 are the same code.
  • the second node 210 designates the first wallet address WA1 as the destination and transmits challenge code cc52 to the user terminal 400.
  • step S324 the user terminal control unit 401 performs 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 electronically 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. The user terminal control unit 401 then returns the signed code cc51s, which is the challenge code cc51 signed with the first private key PK1, to the first node 110, and returns the signed code cc52s, which is the challenge code cc52 signed with the first private key PK1, to the second node 210.
  • 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 in the first wallet W1 as a third non-fungible token T3 having non-fungibility, similar to step S226 in FIG. 5.
  • step S330 in this embodiment the transaction TX14 shown in FIG. 2 is executed.
  • transaction TX14 the first wallet address WA1 and hierarchical ID a2 are described as storage destination information, and the signed code cc51s, which is signature data, is described as stored data information. In this embodiment, an expiration date is set for the signed code cc51s.
  • 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.
  • 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 designated information sp1, which is designated information data, is stored as the third non-fungible token T3 in the hierarchical ID a2 of the first wallet W1, similar to step S232 in FIG. In step S336 in this embodiment, the transaction TX15 shown in FIG. 2 is executed.
  • the first wallet address WA1 and the hierarchical ID a2 are described as storage destination information, and the first designated information sp1, which is designated information data, is described as stored data information. Furthermore, if the first control unit 111 determines that the two codes correspond, it authenticates the second node 210 and, in step S338, notifies the second node 210 that the authentication was successful.
  • step S340 the second control unit 211 stores the second designation information sp2 and the signed code cc52s in the second wallet W2, similar to step S236 in FIG. 2.
  • step S340 in this embodiment the transaction TX22 shown in FIG. 3 is executed.
  • the second wallet address WA2 and the hierarchical IDb2 are described as the storage destination information
  • the signed code cc52s which is the signature data
  • the second designation information sp2 and the signed code cc52s are stored as a fourth non-fungible token T4 that has non-fungibility.
  • Step S342 is similar to step S318 in FIG. 6.
  • 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 first authentication process in which the first node 110 and the second node 210 are swapped. 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 on 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.
  • step S402 the user terminal 400 executes a second request to the first node 110.
  • step S404 the first control unit 111 returns a challenge code cc6 to the user terminal 400.
  • the first control unit 111 authenticates the user through FIDO authentication.
  • the user terminal control unit 401 which has received the challenge code cc6, performs a second local authentication in step S406.
  • the second local authentication refers to local authentication of the user by the user terminal 400, which is performed 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.
  • the user terminal control unit 401 then returns the signed code cc6s to the first node 110.
  • 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.
  • 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 specifies the second wallet W2 by sending the second wallet address WA2, which is the second identifier, as a header to the second node 210. Thus, in this embodiment, the request for the second authentication is requested after the FIDO authentication based on the second local authentication and the second public key authentication is completed. Also, in step S412 in this embodiment, the first control unit 111 further sends the signed code cc31s stored in the first wallet W1 to the second node 210.
  • 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 sends an authentication success notification to the first node 110 in step S416. Then, the first control unit 111 notifies the user terminal 400 that the second authentication was successful in step S418.
  • FIG. 9 shows the second authentication process when verification of the signed code fails in step S414 in FIG. 8.
  • the second control unit 211 designates the second wallet address WA2 as the destination and transmits the challenge code cc71 to the user terminal 400, and returns the challenge code cc72 corresponding to the challenge code cc71 to the first node 110.
  • the challenge code cc71 and the challenge code cc72 are the same code.
  • the first node 110 designates the second wallet address WA2 as the destination and transmits the challenge code cc72 to the user terminal 400.
  • 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 electronically signs the challenge code cc71 and the challenge code cc72 using the second private key PK2 that pairs with the specified second wallet address WA2. The user terminal control unit 401 then 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.
  • 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 that has non-fungibility.
  • step S430 the transaction TX23 shown in FIG. 3 is executed. In the transaction TX23, the second wallet address WA2 and the hierarchical 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. An expiration date may be set for the signed code cc71s stored as the fifth non-fungible token T5.
  • step S432 the first control unit 111 transmits the signed code cc72s and the first wallet address WA1 to the second node 210.
  • step S434 the second control unit 211 determines whether the signed code cc71s and the signed code cc72s correspond to each other. If the second control unit 211 determines that the two codes correspond to each other, in step S436, the second designated information sp2, which is designated information data, is stored in the second wallet W2 as the fifth non-fungible token T5.
  • step S430 the transaction TX24 shown in FIG. 3 is executed.
  • the second wallet address WA2 and the hierarchy Idb3 are described as the storage destination information, and the second designated information sp2, which is designated information data, is described as the stored data information. Furthermore, if the second control unit 211 determines that the two codes correspond, it authenticates the first node 110 and, in step S438, notifies the first node 110 that the authentication was successful.
  • 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, which has non-fungibility, in the first wallet W1.
  • step S432 the transaction TX16 shown in FIG. 2 is executed.
  • transaction TX16 the first wallet address WA1 and hierarchical ID a3 are described as storage destination information, and the first designation information sp1, which is designation information data, is described as stored data information.
  • Step S442 is similar to step S418 in FIG. 8.
  • the authentication method of this embodiment is realized by executing the steps of the pre-registration process, the linking process, the first authentication process, and the second authentication process described above.
  • the first control unit 111 authenticates the second node 210 in the first authentication, it provides the second node 210 with the first information inf1. In this case, the first control unit 111 provides the second node 210 with the first information inf1 acquired from the first database 190.
  • the second control unit 211 authenticates the first node 110 in the second authentication, it provides the first node 110 with the second information inf2 acquired from the second database 290.
  • FIG. 1 an example of the acquisition path of the second information inf2 by the first control unit 111 and an example of the acquisition path of the first information inf1 by the second control unit 211 are shown by dashed lines. Note that, for example, before providing the first information inf1 and the second information inf2, a second verification of the correspondence of the signed code may be performed.
  • the first control unit 111 When the first control unit 111 provides the second node 210 with the first information inf1, the first control unit 111 records in the first distributed ledger DL1 the 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 the second provision information indicating that the second information inf2 has been provided to the first node 110.
  • 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 added to each distributed ledger. As an example of such a transaction, FIG.
  • FIG. 2 shows 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 specification information sp1 or the second specification information sp2.
  • 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
  • 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.
  • the first control unit 111 requests the second authentication by designating the second wallet W2 using the first designation information sp1.
  • first decentralized network 101 and the second decentralized network 201 are linked by a linking application such as a decentralized exchange (DEX), DEX or the like can be a security weakness. In this embodiment, since DEX or the like is not required, such security risks can be suppressed.
  • first decentralized network 101 and the second decentralized network 201 are linked via a decentralized network for linking, it is usually necessary to make the standards of the first decentralized network 101 and the second decentralized network 201 conform to the standards of the decentralized network for linking.
  • the decentralized network for linking configured as a blockchain network is also called a relay chain. In this embodiment, since a relay chain or the like is not required, the first decentralized network 101 and the second decentralized network 201 can be easily linked.
  • the first distributed ledger DL1 and the second distributed ledger DL2 are each configured using a blockchain
  • the storage of the first information inf1 in the first wallet W1 and the storage of the first specified information sp1 are each realized by a transaction stored in a block added to the first distributed ledger DL1
  • the storage of the second information inf2 in the second wallet W2 and the storage of the second specified information sp2 are each realized by a transaction stored in a block added to 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
  • 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.
  • 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, security risks can be further reduced.
  • the first signed code is stored in the first wallet W1 as the first non-fungible token T1
  • the second signed code is stored in the second wallet W2 as the second non-fungible token T2.
  • the second control unit 211 receives the first request, it transmits the second signed code to the first node 110.
  • 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.
  • an expiration date is set for the first signed code stored as the first non-fungible token T1
  • the first control unit 111 determines in the first authentication whether the first signed code, whose expiration date has not expired, corresponds to the second signed code. Therefore, the second node 210 can be authenticated if the expiration date of the first signed code has not expired, so that security risks in the first authentication can be further reduced.
  • the first control unit 111 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 improves the tamper resistance of the first distributed ledger DL1.
  • the first control unit 111 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 reduced 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.
  • the second control unit 211 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.
  • 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 properly authenticate the user terminal 400 using local authentication and public key authentication, and then request authentication of each node.
  • 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. Portions of the configuration of the authentication system 10b that are not particularly described are similar to those of the first embodiment.
  • the third network system 300 includes a third distributed network 301 configured with multiple third nodes 310.
  • the third distributed network 301 is connected to the Internet INT, similar to other networks and user terminals 400 in the authentication system 10b.
  • the third nodes 310 are 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.
  • the second wallet W2 stores the third designation information sp3 that designates the third wallet W3 of the third distributed ledger as a 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.
  • the first designation information sp1 is stored as an eighth non-fungible token T8 having non-fungibility.
  • 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 executing a process similar to the cooperation process in FIG. 5 between the user terminal 400, the second node 210, and the third node 310.
  • the third specification information sp3 is not stored in the first wallet W1, but the first control unit 111 can obtain the third information inf3 via the second node 210. More specifically, for example, the first control unit 111 causes the second node 210 to authenticate the first node 110 using the first specification 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 specification 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 Figures 6 and 7 being executed between the user terminal 400, the second node 210, and the third node 310.
  • the second control unit 211 obtains, 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.
  • 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 Figures 8 and 9 between the user terminal 400, the second node 210, and the third node 310.
  • the authentication system 10b may include, for example, four or more distributed networks.
  • 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. Portions of the configuration of the authentication system 10c that are not particularly described are similar to those of the first embodiment.
  • the fourth network system 500 includes a network 501 that is not distributed.
  • 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 in the same way as the other networks and the user terminal 400 in the authentication system 10c.
  • the fourth network system 500 is configured as a centralized network in a medical institution.
  • 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 memory unit 512, and an input/output interface.
  • the terminal device 510 is configured to be able to access fourth information inf4 related to the user who uses the user terminal 400.
  • the fourth information inf4 is an ID given to the user as an identification number for the patient at the medical institution, and is stored in a database DB in the memory unit 512.
  • the database DB in the storage unit 512 stores the URI of the fourth information inf4 and the first specification information sp1, with the address Ad unique in the database DB as the primary key.
  • the second wallet W2 stores the fourth specification information sp4 as a ninth non-fungible token T9 that is non-fungible.
  • the fourth specification information sp4 specifies 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 specification information sp4 is expressed in the format of "fifth identifier: sixth identifier" in FIG. 11.
  • 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.
  • the fourth specification information sp4 is stored in the second wallet W2, and the first specification information sp1 is stored in the database DB with the address Ad as the primary key, so that the network 501 and the second distributed network 201 are in a linked state.
  • 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 in FIG. 5 between the user terminal 400, the second node 210, and the terminal device 510.
  • the fourth control unit 511 transmits the signed challenge code and the address Ad to the second node 210.
  • the fourth control unit 511 stores the URI of the fourth information inf4 and the first specification information sp1 in the storage unit 512 with the address Ad as the primary key.
  • the fourth control unit 511 in response to a request from the user terminal control unit 401, can use the first specification information sp1 to request the second node 210 to authenticate the terminal device 510 based on the ninth non-fungible token T9.
  • the authentication of the terminal device 510 by the second node 210 is realized, for example, by a process similar to the first authentication process shown in Figures 6 and 7 being executed 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.
  • the second control unit 211 can use the fourth specification information sp4 to request the terminal device 510 to authenticate the second node 210 based on the first specification information sp1 stored with the address Ad as the primary key.
  • 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.
  • the fourth control unit 511 may obtain the first information inf1 via the second node 210, for example, as described in the third embodiment.
  • the first control unit 111 may obtain the fourth information inf4 via the second node 210.
  • the first distributed network 101 and a non-distributed network may be in a linked state, or one distributed network may be in a linked state with two or more non-distributed networks.
  • the first network system 100 is configured as a management system for personal numbers
  • the second network system 200 is configured as a management system for medical data.
  • each network system may not be configured in this way.
  • the first network system 100 may be configured as a management system for medical data
  • the second network system 200 may be configured as a management system for personal numbers.
  • each network system may be configured as another system, such as a system for managing financial data.
  • each network system may be configured as a system for providing a virtual space service, such as a so-called metaverse.
  • the first information inf1 and the second information inf2 may be data representing items owned by a user in a virtual space, for example.
  • the first distributed ledger DL1 and the second distributed ledger DL2 are configured using a blockchain.
  • the first distributed ledger DL1 and the second distributed ledger DL2 do not have to be configured using a blockchain, and may be configured as a distributed ledger of another type.
  • the first distributed ledger DL1 and the second distributed ledger DL2 may be configured using a directed acyclic graph, a hash graph, a holochain, etc.
  • the first designation information sp1 includes the first identifier and the second identifier, but it does not have to include the first identifier and the second identifier.
  • the first designation information sp1 may be represented by one identifier that uniquely represents the "distributed ledger wallet" itself.
  • the second designation information sp2 does not have to include the third identifier and the fourth identifier.
  • the first control unit 111 determines whether the first signed code and the second signed code correspond in the first authentication, and authenticates the second node 210 if the two codes correspond. In contrast, the first control unit 111 does not need to authenticate the second node 210 in this way in the first authentication, and may, for example, verify whether the second wallet address WA2 sent 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. Similarly, the second control unit 211 does not need to determine whether the first signed code and the second signed code correspond in the second authentication.
  • 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 ID a1 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.
  • 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.
  • a null value may be stored as signature data in hierarchical ID a2 of first wallet W1 in step S340 of FIG. 7.
  • 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.
  • the first control unit 111 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 contrast, 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.
  • 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 performed.
  • 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.
  • 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... storage unit, 404... program, 410... display unit, 500... fourth network system, 501... network, 510... terminal device, 511... fourth control unit, 512... storage unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

認証システムにおいて、ユーザに関する第１情報にアクセス可能な複数の第１ノードによって共有される第１分散型台帳の第１ウォレットに、第１情報のＵＲＩと、ユーザに関する第２情報にアクセス可能な複数の第２ノードによって共有される第２分散型台帳の第２ウォレットを指定する第１指定情報とが格納され、第２ウォレットに、第２情報のＵＲＩと第１ウォレットを指定する第２指定情報とが格納され、第１指定情報と第２指定情報とは、非代替性を有するトークンとして格納され、第２ノードは、ユーザ端末からの要求に応じて、第２指定情報を用いて、第１ノードにユーザのための第２ノードの認証を要求し、第１ノードは、ユーザ端末の制御部からの要求に応じて、第１指定情報を用いて、第２ノードにユーザのための第１ノードの認証を要求する。

Description

認証システム、ユーザ端末、認証方法、および、プログラム 関連出願の相互参照
　本願は、２０２２年９月２９日に出願された出願番号２０２２－１５６２９８号の日本特許出願に基づく優先権を主張し、その開示の全てが参照によって本願に組み込まれる。
　本開示は、認証システム、ユーザ端末、認証方法、および、プログラムに関する。
　中央集権的な情報管理システムには、大規模な情報漏洩や、基幹部の障害による機能停止等のリスクがある。このようなリスクを回避する技術として、分散型ネットワークによって情報を分散的に管理する技術が知られている（例えば、特許文献１）。
特表２０２０－５０７１４３号公報
　単に既存の各情報管理システムに分散型ネットワークを適用した場合、各情報管理システムの分散型ネットワークがサイロ化する。そのため、ユーザの利便性向上のためには、分散型ネットワーク同士を連携させ、各ネットワーク間の相互運用性を高めることが望まれる。しかしながら、例えば、ネットワーク同士の連携のために、各ネットワーク間でユーザに関する情報を共有することや、各ネットワーク間でユーザに関する情報を授受する機会が増えることは、情報漏洩の観点でリスクがある。そのため、セキュリティ上のリスクを低減しつつ、分散型ネットワーク同士を適切に連携できる技術が望まれていた。
　本開示は、以下の形態として実現することが可能である。
（１）本開示の一形態によれば、認証システムが提供される。この認証システムは、第１分散型台帳を共有し、ユーザに関する第１情報にアクセス可能な複数の第１ノードによって構成された第１分散型ネットワークと、第２分散型台帳を共有し、前記ユーザに関する第２情報にアクセス可能な複数の第２ノードによって構成された第２分散型ネットワークと、前記ユーザによって使用され、ユーザ端末制御部を有するユーザ端末と、を備える。前記第１ノードは、第１制御部を有し、前記第２ノードは、第２制御部を有する。前記第１分散型台帳の第１ウォレットには、前記第１情報のＵＲＩと、前記第２分散型台帳の第２ウォレットを指定する第１指定情報と、が格納され、前記第１指定情報は、非代替性を有するトークンである第１非代替性トークンとして格納される。前記第２分散型台帳の前記第２ウォレットには、前記第２情報のＵＲＩと、前記第１ウォレットを指定する第２指定情報と、が格納され、前記第２指定情報は、非代替性を有するトークンである第２非代替性トークンとして格納される。前記第２制御部は、前記ユーザ端末制御部からの第１要求に応じて、前記第２指定情報を用いて前記第１ウォレットを指定することで、前記第１ノードに、前記第１非代替性トークンに基づいて前記ユーザのために前記第２ノードを認証する第１認証を要求する。前記第１制御部は、前記ユーザ端末制御部からの第２要求に応じて、前記第１指定情報を用いて前記第２ウォレットを指定することで、前記第２ノードに、前記第２非代替性トークンに基づいて前記ユーザのために前記第１ノードを認証する第２認証を要求する。
　このような形態によれば、第１指定情報を用いて第２ウォレットを指定することによって第１ノードの認証を要求でき、第２指定情報を用いて第１ウォレットを指定することによって第２ノードの認証を要求できる。そのため、各ノードが認証を要求する場合に、各ノードが第１情報や第２情報を共有することや、各ノード間で第１情報や第２情報を授受することを要しない。従って、第１ノードや第２ノードの認証が実行される場合のセキュリティ上のリスクを低減でき、第１分散型ネットワークと第２分散型ネットワークとを適切に連携できる。
（２）上記形態において、前記第１分散型台帳および前記第２分散型台帳は、それぞれ、ブロックチェーンによって構成され、前記第１ウォレットへの前記第１情報のＵＲＩの格納と、前記第１指定情報の格納とは、それぞれ、前記第１分散型台帳に追加されるブロックに格納されるトランザクションによって実現され、前記第２ウォレットへの前記第２情報のＵＲＩの記録と、前記第２指定情報の記録とは、それぞれ、前記第２分散型台帳に追加されるブロックに格納されるトランザクションによって実現されてもよい。このような形態によれば、第１分散型ネットワークおよび第２分散型ネットワークを、それぞれ、ブロックチェーンネットワークとして構成できる。そのため、中央集権的な情報管理によるリスクをより低減できる。
（３）上記形態において、前記第１指定情報は、前記第２分散型ネットワークを表す第１識別子と、前記第２分散型台帳において一意の第２識別子とを含み、前記第１識別子と前記第２識別子との組み合わせによって前記第２ウォレットを指定し、前記第２指定情報は、前記第１分散型ネットワークを表す第３識別子と、前記第１分散型台帳において一意の第４識別子とを含み、前記第３識別子と前記第４識別子との組み合わせによって前記第１ウォレットを指定し、前記第２制御部は、前記第１要求に応じて、前記第１ノードに前記第３識別子を送信することによって、前記第１ウォレットを指定し、前記第１制御部は、前記第２要求に応じて、前記第２ノードに前記第２識別子を送信することによって、前記第２ウォレットを指定してもよい。このような形態によれば、各ノード間で第２識別子や第４識別子を授受することによって、簡易に各ノードの認証を要求できる。
（４）上記形態において、前記第１ウォレットには、前記ユーザ端末の秘密鍵を用いて署名済みの第１認証コードである第１署名済みコードが、前記第１非代替性トークンとして格納され、前記第２ウォレットには、前記秘密鍵を用いて署名済みの、前記第１認証コードと対応する第２認証コードである、第２署名済みコードが、前記第２非代替性トークンとして格納され、前記第２制御部は、前記第１要求が実行された場合、前記第１ノードに前記第２署名済みコードを送信し、前記第１制御部は、前記第１認証が要求された場合、前記第１署名済みコードと前記第２署名済みコードとが対応するか否かを判定し、前記第１署名済みコードと前記第２署名済みコードとが対応する場合、前記第２ノードを認証してもよい。このような形態によれば、第１非代替性トークンとしての第１署名済みコードと、第２非代替性トークンとしての第２署名済みコードとの対応性を検証することによって、簡易に第２ノードを認証できる。
（５）上記形態において、前記第１非代替性トークンとして格納された前記第１署名済みコードには、有効期限が設定され、前記第１制御部は、前記第１認証が要求された場合、前記有効期限が満了していない前記第１署名済みコードと前記第２署名済みコードとが対応するか否かを判定してもよい。このような形態によれば、第１署名済みコードの有効期限が満了していない場合に第２ノードを認証できるので、第１認証において、セキュリティ上のリスクをより抑制できる。
（６）上記形態において、前記第１制御部は、前記第２ノードを認証した場合、前記第２ノードに前記第１情報を提供し、前記第１分散型台帳に、前記第２ノードに前記第１情報を提供したことを表す情報を記録してもよい。このような形態によれば、第１分散型台帳の耐改竄性を向上できる。
（７）上記形態において、前記第１情報は、前記第１分散型ネットワークから参照可能な第１データベースに格納され、前記第２情報は、前記第２分散型ネットワークから参照可能な第２データベースに格納され、前記第１制御部は、前記第２ノードを認証した場合、前記第２ノードに対して、前記第１データベースから取得した前記第１情報を提供し、前記第２制御部は、前記第１ノードを認証した場合、前記第１ノードに対して、前記第２データベースから取得した前記第２情報を提供してもよい。このような形態によれば、例えば、第２ノードが第１情報に直接アクセスする形態や、第１ノードが第２情報に直接アクセスする形態と比較して、セキュリティ上のリスクをより抑制できる。
（８）上記形態において、前記第２制御部は、前記第１要求が実行された場合、前記ユーザ端末による前記ユーザの第１ローカル認証と、前記第１ローカル認証の後に前記第２制御部によって実行される前記ユーザ端末の第１公開鍵認証と、が完了した後に、前記第１ノードに前記第１認証を要求し、前記第１制御部は、前記第２要求が実行された場合、前記ユーザ端末による前記ユーザの第２ローカル認証と、前記第２ローカル認証の後に前記第１制御部によって実行される前記ユーザ端末の第２公開鍵認証と、が完了した後に、前記第２ノードに前記第１認証を要求してもよい。このような形態によれば、各ノードがユーザ端末から第１要求や第２要求を受けた場合に、ローカル認証と公開鍵認証とを用いて適切にユーザ端末を認証した後で、各ノードの認証を要求できる。
　本開示は、認証システム以外の種々の形態として実現することも可能である。例えば、ユーザ端末や、認証方法の形態として実現できる。また、本開示は、分散型ネットワークシステムや、コンピュータプログラムが記録された一時的でない有形な記録媒体等の種々の形態で実現することが可能である。
第１実施形態における認証システムを示す説明図である。 第１分散型台帳を説明する図である。 第２分散型台帳を説明する図である。 事前登録処理を示す説明図である。 連携処理を示す説明図である。 第１認証処理を示す第１の図である。 第１認証処理を示す第２の図である。 第２認証処理を示す第１の図である。 第２認証処理を説明する第２の図である。 第２実施形態における認証システムを示す説明図である。 第３実施形態における認証システムを示す説明図である。
Ａ．第１実施形態：
　図１は、本実施形態における認証システム１０を示す説明図である。認証システム１０は、第１ネットワークシステム１００と、第２ネットワークシステム２００と、ユーザ端末４００とを備える。ネットワークシステム同士、および、各ネットワークシステムとユーザ端末４００とは、インターネットＩＮＴを介して相互に通信可能に構成されている。
　第１ネットワークシステム１００は、複数の第１ノード１１０によって構成された第１分散型ネットワーク１０１を備える。各第１ノード１１０は、Ｐ２Ｐ（Peer to Peer）によって互いに接続されている。本実施形態では、第１ネットワークシステム１００は、更に、第１分散型ネットワーク１０１からアクセス可能な第１データベース１９０を備える。第１ネットワークシステム１００は、公的サービスの提供のために個人に付与される個人番号を管理する管理システムとして構成されている。分散型ネットワークを備えるネットワークシステムのことを、分散型ネットワークシステムとも呼ぶ。
　各第１ノード１１０は、ユーザ端末４００を使用するユーザに関する第１情報ｉｎｆ１にアクセス可能に構成されている。本実施形態では、第１情報ｉｎｆ１は、ユーザに付与された個人番号であり、第１データベース１９０に格納されている。
　各第１ノード１１０は、第１分散型台帳ＤＬ１を共有する。本実施形態では、第１分散型台帳ＤＬ１は、ブロックチェーンによって構成されている。これによって、第１分散型ネットワーク１０１は、ブロックチェーンネットワークとして構成されている。分散型台帳を構成するブロックチェーンは、例えば、パブリック型であってもよいし、プライベート型であってもよい。また、例えば、ブロックチェーンネットワークを構成する複数のノードのうちの一部は、フルノードでなくてもよく、軽量ノードであってもよい。
　第１ノード１１０は、第１制御部１１１を備える。第１制御部１１１は、ＣＰＵと、記憶部と、外部との信号の入出力を行う入出力インターフェイスとを備えるコンピュータによって構成される。第１制御部１１１に備えられた記憶部は、第１分散型台帳ＤＬ１を記憶する。また、第１制御部１１１に備えられたＣＰＵが記憶部に記憶されたプログラムを実行することにより、第１分散型台帳ＤＬ１でトランザクションを実行する機能や、後述する第２認証を要求する機能等、種々の機能を第１制御部１１１に実現させる。
　第２ネットワークシステム２００は、複数の第２ノード２１０によって構成された第２分散型ネットワーク２０１を備える。各第２ノード２１０は、Ｐ２Ｐによって互いに接続されている。本実施形態では、第２ネットワークシステム２００は、更に、第２分散型ネットワーク２０１からアクセス可能な第２データベース２９０を備える。第２ネットワークシステム２００は、個人の医療データを管理する管理システムとして構成されている。
　各第２ノード２１０は、ユーザに関する第２情報ｉｎｆ２にアクセス可能に構成されている。本実施形態では、第２情報ｉｎｆ２は、ユーザの医療データを管理するための管理ＩＤであり、第２データベース２９０に格納されている。
　各第２ノード２１０は、第２分散型台帳ＤＬ２を共有する。本実施形態では、第２分散型台帳ＤＬ２は、第１分散型台帳ＤＬ１と同様にブロックチェーンによって構成される。
　第２ノード２１０は、第２制御部２１１を備える。第２制御部２１１は、第１制御部１１１と同様にコンピュータによって構成され、ＣＰＵと記憶部と入出力インターフェイスとを備える。第２制御部２１１に備えられた記憶部は、第２分散型台帳ＤＬ２を記憶する。また、第２制御部２１１に備えられたＣＰＵが、記憶部に記憶されたプログラムを実行することにより、第２分散型台帳ＤＬ２でトランザクションを実行する機能や、後述する第１認証を要求する機能等、種々の機能を第２制御部２１１に実現させる。
　ユーザ端末４００は、ユーザによって使用される。ユーザ端末４００は、ユーザ端末制御部４０１と、表示部４１０とを備える。ユーザ端末制御部４０１は、第１制御部１１１と同様にコンピュータによって構成され、ＣＰＵと記憶部４０３と入出力インターフェイスとを備える。第１制御部１１１に備えられたＣＰＵは、記憶部４０３に記憶されたプログラム４０４を実行することにより、例えば、後述する第１要求を実行する機能や、第２要求を実行する機能等の種々の機能をユーザ端末制御部４０１に実現させる。プログラム４０４は、例えば、ユーザ端末制御部４０１で使用可能な専用アプリケーションプログラムであってもよいし、ユーザ端末制御部４０１で使用可能な汎用アプリケーション（例えば、ウェブブラウザ）の機能を拡張する機能拡張プログラムであってもよい。表示部４１０は、タッチ操作可能な液晶ディスプレイとして構成され、入力部や操作部を兼ねる。
　図２は、第１分散型台帳ＤＬ１を説明する図である。第１分散型台帳ＤＬ１は、第１ウォレットＷ１を有する。第１ウォレットＷ１は、第１分散型台帳ＤＬ１において、第１分散型台帳ＤＬ１で一意の第１ウォレットアドレスＷＡ１によって指定される。本実施形態では、第１ウォレットＷ１は、第１ウォレットＷ１内の階層ごとに、各データを格納可能に構成されている。第１ウォレットＷ１内の各階層には、例えば、ＵＲＩ（Uniform Resource Identifier）データや、指定情報データ、署名データ、公開鍵データ、提供情報データ等が格納可能である。例えば、第１ウォレットＷ１の直下には、ＵＲＩデータとして第１情報ｉｎｆ１のＵＲＩが格納され、公開鍵データとして第１公開鍵ＯＫ１が格納されている。第１ウォレットＷ１内の階層ＩＤａ１には、指定情報データとして、第２分散型台帳ＤＬ２の第２ウォレットＷ２を指定する第１指定情報ｓｐ１が格納され、署名データとして署名済みコードｃｃ３１ｓが格納されている。
　第１指定情報ｓｐ１は、非代替性を有するトークンである第１非代替性トークンＴ１として、第１ウォレットＷ１に格納される。非代替性を有するトークンとは、いわゆる暗号資産（仮想通貨とも呼ばれる）等の代替可能なトークンと異なり、代替不可能な固有のトークンであることを表す。第１指定情報ｓｐ１は、例えば、ＥＲＣ－７２１やＥＲＣ－１１５５、ＥＲＣ－４９０７等のトークン規格に準拠するＮＦＴ（non-fungible token）として格納される。また、本実施形態では、署名済みコードｃｃ３１ｓも、第１指定情報ｓｐ１と同様に、第１非代替性トークンＴ１として第１ウォレットＷ１に格納される。
　図２には、第１分散型台帳ＤＬ１において実行されるトランザクションを表すトランザクションデータＴＤ１が示されている。本実施形態では、上述した第１ウォレットＷ１への情報の格納は、第１分散型台帳ＤＬ１においてトランザクションが実行されることによって実現される。トランザクションデータＴＤ１に含まれる各トランザクションは、ブロックチェーンによって構成された第１分散型台帳ＤＬ１に追加されるブロックに格納される。なお、図２には、技術の理解を容易にするために、第１ウォレットＷ１内の各データをトランザクションデータＴＤ１と別に示したが、本実施形態における第１ウォレットＷ１内の各データは、実際には、トランザクションデータＴＤ１によって実現されている。
　トランザクションデータＴＤ１に含まれる各トランザクションには、そのトランザクションによる情報の格納先を表す格納先情報と、格納先に格納されるデータおよびそのデータの属性を表す格納データ情報とが記述される。格納先情報としては、格納先のウォレットを指定するウォレットアドレスに加え、格納先のウォレット内の階層を更に指定する情報が記述可能に構成されている。格納データ情報は、図２において、「属性：データ」の形式で表されている。例えば、トランザクションＴＸ１２には、格納先情報として、第１ウォレットＷ１を指定する第１ウォレットアドレスＷＡ１と、第１ウォレットＷ１の階層ＩＤａ１とが記述され、データ情報として、署名データである署名済みコードｃｃ１ｓが記述されている。トランザクションＴＸ１２が実行されることで、第１ウォレットアドレスＷＡ１によって指定される第１ウォレットＷ１に、署名データとして署名済みコードｃｃ１ｓが格納される。なお、トランザクションＴＸ１１には、格納先の階層を指定する情報が記述されていない。本実施形態では、格納先の階層が記述されていないトランザクションが実行された場合、そのトランザクションのデータ情報に記述されたデータは、ウォレットアドレスによって指定されるウォレットの直下に格納される。
　図３は、第２分散型台帳ＤＬ２を説明する図である。第２分散型台帳ＤＬ２は、第２ウォレットＷ２を有する。第２ウォレットＷ２は、第２分散型台帳ＤＬ２において、第２分散型台帳ＤＬ２で一意の第２ウォレットアドレスＷＡ２によって指定される。本実施形態では、第２ウォレットＷ２は、第１ウォレットＷ１と同様に、第２ウォレットＷ２内の階層ごとに、各データを格納可能に構成されている。例えば、第２ウォレットＷ２内の階層ＩＤｂ１には、ＵＲＩデータとして第２情報ｉｎｆ２のＵＲＩが格納され、指定情報データとして第２指定情報ｓｐ２が格納され、署名データとして署名済みコードｃｃ３２ｓが格納され、公開鍵データとして第２公開鍵ＯＫ２が格納されている。第２指定情報ｓｐ２は、第１指定情報ｓｐ１と同様に、非代替性を有するトークンである第２非代替性トークンＴ２として、第２ウォレットＷ２に格納される。また、本実施形態では、署名済みコードｃｃ３２ｓも、第２非代替性トークンＴ２として第２ウォレットＷ２に格納される。
　図３には、第２分散型台帳ＤＬ２において実行されるトランザクションを表すトランザクションデータＴＤ２が示されている。第２ウォレットＷ２への情報の格納は、第２分散型台帳ＤＬ２においてトランザクションが実行されることによって実現される。トランザクションデータＴＤ２に含まれる各トランザクションは、第２分散型台帳ＤＬ２に追加されるブロックに格納される。本実施形態では、第２ウォレットＷ２内の各データは、第１ウォレットＷ１と同様に、トランザクションデータＴＤ２によって実現されている。トランザクションデータＴＤ２に含まれる各トランザクションには、トランザクションデータＴＤ１と同様に、格納先情報と格納データ情報とが記述される。
　本実施形態では、第１指定情報ｓｐ１および第２指定情報ｓｐ２は、多階層登録型のデータ構造によって表される。より詳細には、第１指定情報ｓｐ１は、第２分散型ネットワーク２０１を表す第１識別子と、第２分散型台帳ＤＬ２において一意の第２識別子とを含む。第１指定情報ｓｐ１は、第１識別子と第２識別子との組み合わせによって第２ウォレットＷ２を指定する。図２において、第１指定情報ｓｐ１は、「第１識別子：第２識別子」の形式で表されている。本実施形態では、第１識別子は、第２分散型ネットワーク２０１のＵＲＮ(Uniform Resource Name)であり、図２において「ＮＴ２」と表されている。第２識別子は、第２ウォレットアドレスＷＡ２である。同様に、図３に示した第２指定情報ｓｐ２は、第１分散型ネットワーク１０１を表す第３識別子と、第１分散型台帳ＤＬ１において一意の第４識別子とを含む。図３において、第２指定情報ｓｐ２は、「第３識別子：第４識別子」の形式で表されている。第２指定情報ｓｐ２は、第３識別子と第４識別子との組み合わせによって第２ウォレットＷ２を指定する。本実施形態では、第３識別子は、第１分散型ネットワーク１０１のＵＲＮであり、図３において「ＮＴ１」と表されている。第４識別子は、第１ウォレットアドレスＷＡ１である。
　図４は、事前登録処理を示す説明図である。図５は、連携処理を示す説明図である。連携処理とは、第１ウォレットＷ１に第１指定情報ｓｐ１を格納させ、かつ、第２ウォレットＷ２に第２指定情報ｓｐ２を格納させる処理のことを指す。事前登録処理とは、連携処理に先立って、第１ウォレットＷ１に第１情報ｉｎｆ１を格納させる処理のことを指す。第１連携処理が実行されることで、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とが連携状態となる。ある２つのネットワークが連携状態にある場合、各ネットワークを構成するノードが、相互にノード認証を要求することが可能になる。ノード認証とは、一方のネットワークを構成するノードの制御部が、ユーザ端末制御部４０１からの要求に応じて、自身の記憶部に格納された指定情報を用いて、他方のネットワークを構成するノードに対して、ユーザのために、自身のノードの認証を要求することを言う。
　より詳細には、例えば、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とが連携状態にある場合、第２制御部２１１が、ユーザ端末制御部４０１からの第１要求に応じて、第２指定情報ｓｐ２を用いて第１制御部１１１に第１認証を要求することが可能になり、かつ、第１制御部１１１が、ユーザ端末制御部４０１からの第２要求に応じて、第１指定情報ｓｐ１を用いて第２制御部２１１に第２認証を要求することが可能になる。第１認証とは、第１ノード１１０が第１非代替性トークンＴ１に基づいてユーザのために第２ノード２１０を認証することを指す。第２認証とは、第２ノード２１０が第２非代替性トークンＴ２に基づいてユーザのために第１ノード１１０を認証することを指す。本実施形態では、第１要求および第１認証は、後述する第１認証処理において実行される。第２要求および第２認証は、後述する第２認証処理において実行される。
　図４に示した事前登録処理は、連携処理に先立って、例えば、ユーザ端末４００において、ユーザによる所定の開始操作が行われた場合に実行される。ステップＳ１０２にて、ユーザ端末制御部４０１は、第１ノード１１０に対する事前登録要求を実行する。本実施形態におけるステップＳ１０２では、ユーザ端末制御部４０１は、第１ノード１１０に、所定の要求メッセージと、第１ノード１１０が第１データベース１９０上で第１情報ｉｎｆ１を識別するための識別情報とを第１ノード１１０に送信する。この識別情報は、例えば、ＩＣカード等に、ユーザ端末４００によって読み取り可能に格納される。
　事前登録要求が実行された場合、第１制御部１１１は、ステップＳ１０４～Ｓ１１２にて、ローカル認証と公開鍵認証とを利用して、ユーザの認証を実行する。より詳細には、第１制御部１１１は、ステップＳ１０４～Ｓ１１２において、ＦＩＤＯ（Fast IDentity Online）認証によってユーザを認証する。ステップＳ１０４にて、第１制御部１１１は、ユーザ端末４００に対して、チャレンジコードｃｃ１を返送する。
　ステップＳ１０６にて、チャレンジコードｃｃ１を受信したユーザ端末制御部４０１は、ユーザのローカル認証を実行する。ローカル認証としては、ユーザ端末４００に備えられたカメラを使用した顔認証や、指紋読み取り装置を使用した指紋認証等の生体認証、ＰＩＮ（Personal Identification Number）を用いた認証、パターン認証等を利用できる。ローカル認証に失敗した場合、ユーザ端末制御部４０１は、所定のエラー処理を実行する。この場合、ユーザ端末制御部４０１は、例えば、表示部４１０やスピーカを介してユーザにエラーを通知するとともに、再度のローカル認証を実行してもよいし、所定の回数、ローカル認証が失敗した場合に事前登録処理を終了させてもよい。ローカル認証に成功した場合、ステップＳ１０８にて、ユーザ端末制御部４０１は、第１秘密鍵ＰＫ１と、第１秘密鍵ＰＫ１と対の第１公開鍵ＯＫ１とを生成する。第１秘密鍵ＰＫ１と第１公開鍵ＯＫ１との生成には、例えば、ＲＳＡ暗号や楕円曲線暗号が用いられる。以下では、第１秘密鍵ＰＫ１のことを単に秘密鍵とも呼び、第１公開鍵ＯＫ１のことを単に公開鍵とも呼ぶ。
　ステップＳ１１０にて、ユーザ端末制御部４０１は、第１秘密鍵ＰＫ１を用いてチャレンジコードｃｃ１に電子署名する。第１秘密鍵ＰＫ１を用いて署名済みのチャレンジコードｃｃ１のことを、署名済みコードｃｃ１ｓとも呼ぶ。その後、ユーザ端末制御部４０１は、署名済みコードｃｃ１ｓと第１公開鍵ＯＫ１とを第１ノード１１０に返送する。
　ステップＳ１１２にて、第１制御部１１１は、第１公開鍵ＯＫ１を用いて、署名済みコードｃｃ１ｓの署名を検証する。署名の検証に失敗した場合、第１制御部１１１は、所定のエラー処理を実行する。この場合、第１制御部１１１は、例えば、ユーザ端末４００にエラーを通知する。署名の検証に成功した場合、第１制御部１１１は、ステップＳ１１４にて、第１分散型台帳ＤＬ１でトランザクションを実行することによって、第１ウォレットアドレスＷＡ１によって指定される第１ウォレットＷ１に、第１情報ｉｎｆ１のＵＲＩと第１公開鍵ＯＫ１とを格納する。第１ウォレットアドレスＷＡ１は、ステップＳ１１６に先立って、第１公開鍵ＯＫ１から不可逆的に生成される。そのため、第１ウォレットアドレスＷＡ１は、第１公開鍵ＯＫ１と同様に、第１秘密鍵ＰＫ１と対となる。
　より詳細には、本実施形態におけるステップＳ１１６では、図２に示したトランザクションＴＸ１１が実行される。トランザクションＴＸ１１には、格納先情報として第１ウォレットアドレスＷＡ１が記述され、格納データ情報として、ＵＲＩデータである第１情報ｉｎｆ１のＵＲＩと、公開鍵データである第１公開鍵ＯＫ１とが記述されている。第１情報ｉｎｆ１のＵＲＩは、例えば、第１制御部１１１によって、ステップＳ１０４で受信された識別情報に基づいて、第１データベース１９０から取得される。「分散型台帳でトランザクションを実行する」とは、分散型台帳を有するノードによってトランザクションを生成し、そのトランザクションを、その分散型台帳を共有する他のノードに伝播させることを指す。これによって、分散型台帳が更新される。より詳細には、本実施形態では、ブロックチェーンによって構成された分散型台帳で生成されたトランザクションは、その分散型台帳を共有する各ノードに伝播され、検証される。検証が成功した場合、トランザクションは、その分散型台帳に追加されるブロックに格納される。ブロックチェーンのコンセサスアルゴリズムとしては、例えば、ＰｏＷ（プルーフオブワーク）や、ＰｏＳ（プルーフオブステーク）、ＰｏＩ（プルーフオブインポータンス）が用いられる。
　ステップＳ１１６にて、第１制御部１１１は、ユーザ端末４００に第１ウォレットアドレスＷＡ１を返送する。ステップＳ１１８にて、ユーザ端末制御部４０１は、第１ウォレットアドレスＷＡ１と第１秘密鍵ＰＫ１とを、記憶部４０３に記憶させる。ステップＳ１１８以降、ユーザ端末制御部４０１は、第１ウォレットアドレスＷＡ１を、記憶部４０３におけるデータの位置を表すパスとしても用いる。
　図５に示した連携処理は、事前登録処理が完了した後に、例えば、ユーザ端末４００において、ユーザによる所定の開始操作が行われた場合に実行される。ステップＳ２０２にて、ユーザ端末制御部４０１は、第２ノード２１０に対する第１連携要求を実行する。ユーザ端末制御部４０１は、ステップＳ２０２で、所定の要求メッセージを第２ノード２１０に送信するとともに、第２分散型ネットワーク２０１との連携を所望する連携先を指定する。本実施形態では、ユーザ端末制御部４０１は、例えば、第１分散型ネットワーク１０１のＵＲＩを第２ノード２１０に送信することによって、連携先として、第１分散型ネットワーク１０１を指定する。第１連携要求が実行された場合、第２制御部２１１は、ステップＳ２０４にて、ユーザ端末４００にチャレンジコードｃｃ２を返送する。
　チャレンジコードｃｃ２を受信したユーザ端末制御部４０１は、ステップＳ２０６にて、第２情報ｉｎｆ２を生成する。第２情報ｉｎｆ２は、例えば、ユーザのメールアドレスに基づいて生成される。次に、ステップＳ２０８にて、ユーザ端末制御部４０１は、図４のステップＳ１０８と同様の方法で、第２秘密鍵ＰＫ２と、第２秘密鍵ＰＫ２と対の第２公開鍵ＯＫ２とを生成する。ステップＳ２１０にて、ユーザ端末制御部４０１は、第２秘密鍵ＰＫ２を用いてチャレンジコードｃｃ２に電子署名する。第２秘密鍵ＰＫ２を用いて署名済みのチャレンジコードｃｃ２のことを、署名済みコードｃｃ２ｓとも呼ぶ。その後、ユーザ端末制御部４０１は、第１ウォレットアドレスＷＡ１と、第２情報ｉｎｆ２と、署名済みコードｃｃ２ｓと、第２公開鍵ＯＫ２とを、第２ノード２１０に返送する。
　ステップＳ２１２にて、第２制御部２１１は、第２公開鍵ＯＫ２を用いて、図４のステップＳ１１２と同様に、署名済みコードｃｃ２ｓの署名を検証する。署名の検証に成功した場合、ステップＳ２１４にて、第２制御部２１１は、第１ノード１１０に対する第２連携要求を実行する。ステップＳ２１４では、第２制御部２１１は、送信先として第１ウォレットアドレスＷＡ１を指定し、所定の要求メッセージを第１ノード１１０に送信する。
　第２連携要求が実行された場合、第１制御部１１１は、ステップＳ２１６にて、送信先として第１ウォレットアドレスＷＡ１を指定してユーザ端末４００にチャレンジコードｃｃ３１を送信するとともに、第２ノード２１０に、チャレンジコードｃｃ３１と対応するチャレンジコードｃｃ３２を返送する。本実施形態では、チャレンジコードｃｃ３１とチャレンジコードｃｃ３２とは、同一のコードである。チャレンジコードｃｃ３１のことを第１認証コードとも呼び、チャレンジコードｃｃ３２のことを第２認証コードとも呼ぶ。
　ステップＳ２１８にて、チャレンジコードｃｃ３２を受信した第２制御部２１１は、送信先として第１ウォレットアドレスＷＡ１を指定して、ユーザ端末４００にチャレンジコードｃｃ３２を送信する。
　両チャレンジコードを受信したユーザ端末制御部４０１は、ステップＳ２２０にて、図４のステップＳ１０６と同様に、ユーザのローカル認証を実行する。ローカル認証に成功した場合、ステップＳ２２２にて、ユーザ端末制御部４０１は、第１秘密鍵ＰＫ１を用いて、チャレンジコードｃｃ３１およびチャレンジコードｃｃ３２に電子署名する。第１秘密鍵ＰＫ１で署名済みのチャレンジコードｃｃ３１のことを、署名済みコードｃｃ３１ｓや、第１署名済みコードとも呼ぶ。第１秘密鍵ＰＫ１で署名済みのチャレンジコードｃｃ３２のことを、署名済みコードｃｃ３２ｓや、第２署名済みコードとも呼ぶ。その後、ユーザ端末制御部４０１は、署名済みコードｃｃ３１ｓを第１ノード１１０に返送し、署名済みコードｃｃ３２ｓを第２ノード２１０に返送する。
　ステップＳ２２４にて、第１制御部１１１は、図４のステップＳ１１２と同様に、第１公開鍵ＯＫ１を用いて、署名済みコードｃｃ３１ｓの署名を検証する。署名の検証に成功した場合、ステップＳ２２６にて、第１制御部１１１は、第１分散型台帳ＤＬ１でトランザクションを実行することによって、第１ウォレットＷ１に、第１公開鍵ＯＫ１を用いて検証された署名済みコードｃｃ３１ｓを、第１非代替性トークンＴ１として格納する。本実施形態におけるステップＳ２２６では、図２に示したトランザクションＴＸ１２が実行される。本実施形態では、署名済みコードｃｃ３１ｓには、有効期限が設定される。
　ユーザ端末制御部４０１から署名済みコードｃｃ３２ｓを受信した第２制御部２１１は、ステップＳ２２８にて、送信先として第１ウォレットアドレスＷＡ１を指定して、署名済みコードｃｃ３２ｓと、第２ウォレットアドレスＷＡ２とを第１ノード１１０に送信する。第２ウォレットアドレスＷＡ２は、例えば、ステップＳ２２８において、第２公開鍵ＯＫ２から不可逆的に生成される。
　ステップＳ２３０にて、第１制御部１１１は、署名済みコードｃｃ３１ｓと署名済みコードｃｃ３２ｓとが対応するか否かを判定する。第１制御部１１１は、ステップＳ２３０では、例えば、署名済みコード同士の対応を直接検証してもよいし、第１公開鍵ＯＫ１によって各署名済みコードをチャレンジコードに復号した後に、チャレンジコード同士の対応を検証してもよい。第１制御部１１１は、署名済みコードｃｃ３１ｓと署名済みコードｃｃ３２ｓとが対応しないと判定した場合、所定のエラー処理を実行する。この場合、第１制御部１１１は、例えば、第２ノード２１０やユーザ端末４００に認証が失敗したことを通知する。第１制御部１１１は、署名済みコードｃｃ３１ｓと署名済みコードｃｃ３２ｓとが対応すると判定した場合、ステップＳ２３２にて、第１分散型台帳ＤＬ１でトランザクションを実行することによって、第１ウォレットＷ１の階層ＩＤａ１に、指定情報データとして、第１指定情報ｓｐ１を格納する。第１指定情報ｓｐ１は、第１非代替性トークンＴ１として格納される。本実施形態におけるステップＳ２３２では、図２に示したトランザクションＴＸ１３が実行される。トランザクションＴＸ１３には、格納先情報として、第１ウォレットアドレスＷＡ１と階層ＩＤａ１とが記述され、格納データ情報として、指定情報データである第１指定情報ｓｐ１が記述されている。ステップＳ２３４にて、第１制御部１１１は、第２ノード２１０に、署名の検証が成功したことを表す検証成功通知を送信する。
　検証成功通知を受信した第２制御部２１１は、ステップＳ２３６にて、第２分散型台帳ＤＬ２でトランザクションを実行することによって、第２ウォレットＷ２に、第２情報ｉｎｆ２のＵＲＩと、第２公開鍵ＯＫ２と、第２指定情報ｓｐ２と、署名済みコードｃｃ３２ｓとを格納する。本実施形態におけるステップＳ２３６では、図３に示したトランザクションＴＸ２１が実行される。トランザクションＴＸ２１には、格納先情報として、第２ウォレットアドレスＷＡ２、および、第２ウォレットＷ２の階層ＩＤｂ１が記述され、格納データ情報として、ＵＲＩデータである第２情報ｉｎｆ２のＵＲＩと、公開鍵データである第２公開鍵ＯＫ２と、指定情報データである第２指定情報ｓｐ２と、署名データである署名済みコードｃｃ３２ｓとが記述される。本実施形態では、第２情報ｉｎｆ２と、第２公開鍵ＯＫ２と、第２指定情報ｓｐ２と、署名済みコードｃｃ３２ｓとは、第２非代替性トークンＴ２として格納される。
　ステップＳ２３８にて、第２制御部２１１は、ユーザ端末４００に第２ウォレットアドレスＷＡ２を送信する。ステップＳ２４０にて、ユーザ端末制御部４０１は、第２ウォレットアドレスＷＡ２と第２秘密鍵ＰＫ２とを、記憶部４０３に記憶させる。ステップＳ２４０以降、ユーザ端末制御部４０１は、第２ウォレットアドレスＷＡ２を、記憶部４０３におけるデータの位置を表すパスとしても用いる。
　図６は、第１認証処理を示す第１の図である。図７は、第１認証処理を説明する第２の図である。図６および図７に示した第１認証処理は、図５に示した連携処理の完了後に、例えば、ユーザ端末４００において、ユーザによる所定の開始操作が行われた場合に実行される。ユーザは、例えば、第１認証処理の完了後に第２制御部２１１に第１情報ｉｎｆ１を取得させるために、第１認証処理を開始させる。ステップＳ３０２にて、ユーザ端末制御部４０１は、第２ノード２１０に対する第１要求を実行する。ユーザ端末制御部４０１は、ステップＳ３０２では、例えば、送信先として第２ウォレットアドレスＷＡ２を指定して、所定の要求メッセージを第２ノード２１０に送信する。第１要求が実行された場合、第２制御部２１１は、ステップＳ３０４にて、ユーザ端末４００にチャレンジコードｃｃ４を返送する。
　第２制御部２１１は、ステップＳ３０６～Ｓ３１０において、ＦＩＤＯ認証によってユーザを認証する。チャレンジコードｃｃ４を受信したユーザ端末制御部４０１は、ステップＳ３０６にて、図４のステップＳ１０６と同様に、ユーザのローカル認証を実行する。ステップＳ３０６のように、第１要求が実行された後に実行されるユーザ端末４００によるユーザのローカル認証のことを、第１ローカル認証とも呼ぶ。
　第１ローカル認証に成功した場合、ステップＳ３０８にて、ユーザ端末制御部４０１は、第２秘密鍵ＰＫ２を用いてチャレンジコードｃｃ４に署名する。第２秘密鍵ＰＫ２を用いて署名済みのチャレンジコードｃｃ４のことを、署名済みコードｃｃ４ｓとも呼ぶ。そして、ユーザ端末制御部４０１は、署名済みコードｃｃ４ｓを第２ノード２１０に返送する。署名済みコードｃｃ４ｓを受信した第２制御部２１１は、ステップＳ３１０にて、図５のステップＳ２１２と同様に、第２公開鍵ＯＫ２を用いて、署名済みコードｃｃ４ｓの署名を検証する。ステップＳ３１０のように、第１ローカル認証の後に第２制御部２１１によって実行されるユーザ端末４００の公開鍵認証のことを、第１公開鍵認証とも呼ぶ。
　署名の検証に成功した場合、ステップＳ３１２にて、第２制御部２１１は、第２指定情報ｓｐ２を用いて第１ウォレットＷ１を指定することで、第１ノード１１０に第１認証を要求する。より詳細には、第２制御部２１１は、ステップＳ３１４で、第１ノード１１０に、第３識別子である第１ウォレットアドレスＷＡ１をヘッダとして送信することによって、第１ウォレットＷ１を指定する。このように、本実施形態では、第１認証の要求は、第１ローカル認証と第１公開鍵認証とによるＦＩＤＯ認証が完了した後に要求される。また、本実施形態におけるステップＳ３１４では、第２制御部２１１は、更に、第２ウォレットＷ２に格納された署名済みコードｃｃ３２ｓを、第１ノード１１０に送信する。
　第１ウォレットアドレスＷＡ１および署名済みコードｃｃ３２ｓを受信した第１制御部１１１は、ステップＳ３１４にて、送信された署名済みコードｃｃ３２ｓと、第１ウォレットＷ１に第１非代替性トークンＴ１として格納された署名済みコードｃｃ３１ｓとが対応するか否かを、図５のステップＳ２３４と同様に検証する。より詳細には、本実施形態におけるステップＳ３１４では、第１制御部１１１は、有効期限が満了していない署名済みコードｃｃ３１ｓと署名済みコードｃｃ３２ｓとが対応するか否かを検証する。第１制御部１１１は、署名済みコードｃｃ３１ｓの有効期限が満了していた場合、署名済みコードｃｃ３１ｓと署名済みコードｃｃ３２ｓとが対応しないと判定する。第１制御部１１１は、両コードが対応すると判定した場合、第２ノード２１０を認証し、ステップＳ３１６にて、第２ノード２１０に第１認証が成功したことを通知する。ステップＳ３１８にて、第２制御部２１１は、ユーザ端末４００に第１認証が成功したことを通知する。
　図７には、第１認証処理のうち、図６のステップＳ３１６で署名済みコードの検証に失敗した場合の処理が示されている。ステップＳ３２０にて、第１制御部１１１は、送信先として第１ウォレットアドレスＷＡ１を指定してユーザ端末４００にチャレンジコードｃｃ５１を送信するとともに、第２ノード２１０に、チャレンジコードｃｃ５１と対応するチャレンジコードｃｃ５２を返送する。本実施形態では、チャレンジコードｃｃ５１とチャレンジコードｃｃ５２とは、同一のコードである。ステップＳ３２２にて、第２ノード２１０は、送信先として第１ウォレットアドレスＷＡ１を指定してユーザ端末４００にチャレンジコードｃｃ５２を送信する。
　ステップＳ３２４にて、ユーザ端末制御部４０１は、図５のステップＳ２２０と同様に、ユーザのローカル認証を実行する。ローカル認証に成功した場合、ステップＳ３２６にて、ユーザ端末制御部４０１は、チャレンジコードｃｃ５１およびチャレンジコードｃｃ５２に、指定された第１ウォレットアドレスＷＡ１と対の第１秘密鍵ＰＫ１を用いて電子署名する。そして、ユーザ端末制御部４０１は、第１秘密鍵ＰＫ１で署名済みのチャレンジコードｃｃ５１である署名済みコードｃｃ５１ｓを第１ノード１１０に返送し、第１秘密鍵ＰＫ１で署名済みのチャレンジコードｃｃ５２である署名済みコードｃｃ５２ｓを第２ノード２１０に返送する。
　ステップＳ３２８にて、第１制御部１１１は、図５のステップＳ２２４と同様に、署名済みコードｃｃ５１ｓの署名を検証する。署名の検証に成功した場合、ステップＳ３３０にて、第１制御部１１１は、図５のステップＳ２２６と同様に、第１ウォレットＷ１に、署名済みコードｃｃ５１ｓを、非代替性を有する第３非代替性トークンＴ３として格納する。本実施形態におけるステップＳ３３０では、図２に示したトランザクションＴＸ１４が実行される。トランザクションＴＸ１４には、格納先情報として、第１ウォレットアドレスＷＡ１、および、階層ＩＤａ２が記述され、格納データ情報として、署名データである署名済みコードｃｃ５１ｓが記述されている。本実施形態では、署名済みコードｃｃ５１ｓには、有効期限が設定される。
　ステップＳ３３２にて、第２制御部２１１は、図５のステップＳ２２８と同様に、署名済みコードｃｃ５２ｓと、第２ウォレットアドレスＷＡ２とを第１ノード１１０に送信する。ステップＳ３３４にて、第１制御部１１１は、図５のステップＳ２３０と同様に、署名済みコードｃｃ５１ｓと署名済みコードｃｃ５２ｓとが対応するか否かを判定する。第１制御部１１１は、両コードが対応すると判定した場合、ステップＳ３３６にて、図５のステップＳ２３２と同様に、第１ウォレットＷ１の階層ＩＤａ２に、指定情報データである第１指定情報ｓｐ１を第３非代替性トークンＴ３として格納する。本実施形態におけるステップＳ３３６では、図２に示したトランザクションＴＸ１５が実行される。トランザクションＴＸ１５には、格納先情報として、第１ウォレットアドレスＷＡ１と階層ＩＤａ２とが記述され、格納データ情報として、指定情報データである第１指定情報ｓｐ１が記述されている。また、第１制御部１１１は、両コードが対応すると判定した場合、第２ノード２１０を認証し、ステップＳ３３８にて、第２ノード２１０に認証が成功したことを通知する。
　ステップＳ３４０にて、第２制御部２１１は、図２のステップＳ２３６と同様に、第２ウォレットＷ２に、第２指定情報ｓｐ２と、署名済みコードｃｃ５２ｓとを格納する。本実施形態におけるステップＳ３４０では、図３に示したトランザクションＴＸ２２が実行される。トランザクションＴＸ２２には、格納先情報として、第２ウォレットアドレスＷＡ２と階層ＩＤｂ２とが記述され、格納データ情報として、指定情報データである第２指定情報ｓｐ２と、署名データである署名済みコードｃｃ５２ｓとが記述される。第２指定情報ｓｐ２と、署名済みコードｃｃ５２ｓとは、非代替性を有する第４非代替性トークンＴ４として格納される。ステップＳ３４２は、図６のステップＳ３１８と同様である。
　図８は、第２認証処理を示す第１の図である。図９は、第２認証処理を説明する第２の図である。第２認証処理は、第１認証処理における第１ノード１１０と第２ノード２１０とを入れ替えた処理と略同様である。より詳細には、図８および図９におけるステップＳ４０２～ステップＳ４４２は、それぞれ、図６および図７におけるステップＳ３０２～ステップＳ３４２と対応する。第２認証処理は、図５に示した連携処理の完了後に、例えば、ユーザ端末４００において、ユーザによる所定の開始操作が行われた場合に実行される。ユーザは、例えば、第２認証処理の完了後に第１制御部１１１に第２情報ｉｎｆ２を取得させるために、第２認証処理を開始させる。
　まず、ステップＳ４０２にて、ユーザ端末４００は、第１ノード１１０に対する第２要求を実行する。ステップＳ４０４にて、第１制御部１１１は、ユーザ端末４００にチャレンジコードｃｃ６を返送する。
　第１制御部１１１は、ステップＳ４０６～Ｓ４１０において、ＦＩＤＯ認証によってユーザを認証する。チャレンジコードｃｃ６を受信したユーザ端末制御部４０１は、ステップＳ４０６にて第２ローカル認証を実行する。第２ローカル認証とは、第２要求が実行された場合に実行される、ユーザ端末４００によるユーザのローカル認証のことを指す。第２ローカル認証に成功した場合、ステップＳ４０８にて、ユーザ端末制御部４０１は、第１秘密鍵ＰＫ１を用いてチャレンジコードｃｃ６に署名する。第１秘密鍵ＰＫ１を用いて署名済みのチャレンジコードｃｃ６のことを、署名済みコードｃｃ６ｓとも呼ぶ。そして、ユーザ端末制御部４０１は、署名済みコードｃｃ６ｓを、第１ノード１１０に返送する。署名済みコードｃｃ６ｓを受信した第１制御部１１１は、ステップＳ４１０にて、第１公開鍵ＯＫ１を用いて、署名済みコードｃｃ６ｓの署名を検証する。ステップＳ４１０のように、第２ローカル認証の後に第１制御部１１１によって実行されるユーザ端末４００の公開鍵認証のことを、第２公開鍵認証とも呼ぶ。
　ステップＳ４１２にて、第１制御部１１１は、第１指定情報ｓｐ１を用いて第２ウォレットＷ２を指定することで、第２ノード２１０に第２認証を要求する。より詳細には、第１制御部１１１は、第２ノード２１０に、第２識別子である第２ウォレットアドレスＷＡ２をヘッダとして送信することで、第２ウォレットＷ２を指定する。このように、本実施形態では、第２認証の要求は、第２ローカル認証と第２公開鍵認証とによるＦＩＤＯ認証が完了した後に要求される。また、本実施形態におけるステップＳ４１２では、第１制御部１１１は、更に、第１ウォレットＷ１に格納された署名済みコードｃｃ３１ｓを、第２ノード２１０に送信する。
　第２認証が要求された場合、第２制御部２１１は、ステップＳ４１４にて、署名済みコード同士の対応を検証する。署名済みコード同士が対応する場合、第２制御部２１１は、ステップＳ４１６にて、第１ノード１１０に対して認証成功通知を送信する。その後、第１制御部１１１は、ステップＳ４１８にて、ユーザ端末４００に第２認証が成功したことを通知する。
　図９には、第２認証処理のうち、図８のステップＳ４１４で署名済みコードの検証に失敗した場合の処理が示されている。ステップＳ４２０にて、第２制御部２１１は、送信先として第２ウォレットアドレスＷＡ２を指定してユーザ端末４００にチャレンジコードｃｃ７１を送信するとともに、第１ノード１１０に、チャレンジコードｃｃ７１と対応するチャレンジコードｃｃ７２を返送する。本実施形態では、チャレンジコードｃｃ７１とチャレンジコードｃｃ７２とは、同一のコードである。ステップＳ４２２にて、第１ノード１１０は、送信先として第２ウォレットアドレスＷＡ２を指定してユーザ端末４００にチャレンジコードｃｃ７２を送信する。
　ステップＳ４２４にて、ユーザ端末制御部４０１は、ユーザのローカル認証を実行する。ローカル認証に成功した場合、ステップＳ４２６にて、ユーザ端末制御部４０１は、チャレンジコードｃｃ７１およびチャレンジコードｃｃ７２に、指定された第２ウォレットアドレスＷＡ２と対の第２秘密鍵ＰＫ２を用いて電子署名する。そして、ユーザ端末制御部４０１は、第２秘密鍵ＰＫ２で署名済みのチャレンジコードｃｃ７１を表す署名済みコードｃｃ７１ｓを第２ノード２１０に返送し、第２秘密鍵ＰＫ２で署名済みのチャレンジコードｃｃ７２を表す署名済みコードｃｃ７２ｓを第１ノード１１０に返送する。
　ステップＳ４２８にて、第２制御部２１１は、第２公開鍵ＯＫ２を用いて署名済みコードｃｃ７１ｓの署名を検証する。署名の検証に成功した場合、ステップＳ４３０にて、第２制御部２１１は、第２ウォレットＷ２に、署名済みコードｃｃ７１ｓを、非代替性を有する第５非代替性トークンＴ５として格納する。ステップＳ４３０では、図３に示したトランザクションＴＸ２３が実行される。トランザクションＴＸ２３には、格納先情報として第２ウォレットアドレスＷＡ２と階層Ｉｄｂ３とが記述され、格納データ情報として署名データである署名済みコードｃｃ７１ｓが記述されている。第５非代替性トークンＴ５として格納される署名済みコードｃｃ７１ｓには、有効期限が設定されてもよい。
　ステップＳ４３２にて、第１制御部１１１は、署名済みコードｃｃ７２ｓと、第１ウォレットアドレスＷＡ１とを第２ノード２１０に送信する。ステップＳ４３４にて、第２制御部２１１は、署名済みコードｃｃ７１ｓと署名済みコードｃｃ７２ｓとが対応するか否かを判定する。第２制御部２１１は、両コードが対応すると判定した場合、ステップＳ４３６にて、第２ウォレットＷ２に、指定情報データである第２指定情報ｓｐ２を、第５非代替性トークンＴ５として格納する。ステップＳ４３０では、図３に示したトランザクションＴＸ２４が実行される。トランザクションＴＸ２４には、格納先情報として第２ウォレットアドレスＷＡ２と階層Ｉｄｂ３とが記述され、格納データ情報として、指定情報データである第２指定情報ｓｐ２が記述されている。また、第２制御部２１１は、両コードが対応すると判定した場合、第１ノード１１０を認証し、ステップＳ４３８にて、第１ノード１１０に認証が成功したことを通知する。
　ステップＳ４４０にて、第１制御部１１１は、第１ウォレットＷ１に、非代替性を有する第６非代替性トークンＴ６として第１指定情報ｓｐ１と署名済みコードｃｃ７２ｓとを格納する。ステップＳ４３２では、図２に示したトランザクションＴＸ１６が実行される。トランザクションＴＸ１６には、格納先情報として、第１ウォレットアドレスＷＡ１と階層ＩＤａ３とが記述され、格納データ情報として、指定情報データである第１指定情報ｓｐ１が記述されている。ステップＳ４４２は、図８のステップＳ４１８と同様である。
　以上で説明した事前登録処理と、連携処理と、第１認証処理と、第２認証処理との各工程が実行されることによって、本実施形態における認証方法が実現される。
　本実施形態では、第１制御部１１１は、第１認証において第２ノード２１０を認証した場合、第２ノード２１０に第１情報ｉｎｆ１を提供する。この場合、第１制御部１１１は、第２ノード２１０に対して、第１データベース１９０から取得した第１情報ｉｎｆ１を提供する。同様に、第２制御部２１１は、第２認証において第１ノード１１０を認証した場合、第１ノード１１０に、第２データベース２９０から取得した第２情報ｉｎｆ２を提供する。図１には、第１制御部１１１による第２情報ｉｎｆ２の取得経路の例と、第２制御部２１１による第１情報ｉｎｆ１の取得経路の例とが、一点鎖線で示されている。なお、第１情報ｉｎｆ１や第２情報ｉｎｆ２の提供に先立って、例えば、再度の署名済みコードの対応の検証が実行されてもよい。
　第１制御部１１１は、第２ノード２１０に第１情報ｉｎｆ１を提供した場合、第１分散型台帳ＤＬ１に、第２ノード２１０に第１情報ｉｎｆ１を提供したことを表す第１提供情報を記録する。同様に、第２制御部２１１は、第２分散型台帳ＤＬ２に、第１ノード１１０に第２情報ｉｎｆ２を提供したことを表す第２提供情報を記録する。本実施形態では、第１提供情報や第２提供情報の記録は、各分散型台帳で、各分散型台帳に追加されるブロックに格納されるトランザクションが実行されることで実現される。図２には、このようなトランザクションの例として、格納先情報として第１ウォレットアドレスＷＡ１および階層ＩＤａ４が記述され、格納データ情報として提供情報データである第１提供情報ＰＲ１が記述されたトランザクションＴＸ１７が示されている。各提供情報は、例えば、第１情報ｉｎｆ１や第２情報ｉｎｆ２のＵＲＩと、第１指定情報ｓｐ１や第２指定情報ｓｐ２とによって表されてもよい。
　以上で説明した本実施形態における認証システム１０によれば、第１ウォレットＷ１に、第１情報ｉｎｆ１のＵＲＩと、第１非代替性トークンＴ１としての第１指定情報ｓｐ１とが格納され、第２ウォレットＷ２に、第２情報ｉｎｆ２のＵＲＩと、第２非代替性トークンＴ２としての第２指定情報ｓｐ２とが格納される。第２制御部２１１は、第１要求に応じて、第２指定情報ｓｐ２を用いて第１ウォレットＷ１を指定することで、第１認証を要求する。第１制御部１１１は、第２要求に応じて、第１指定情報ｓｐ１を用いて第２ウォレットＷ２を指定することで、第２認証を要求する。これによって、第１指定情報ｓｐ１を用いることで第１ノード１１０の認証を要求でき、第２指定情報ｓｐ２を用いることで第２ノード２１０の認証を要求できる。そのため、各ノードが認証を要求する場合に、各ノードが第１情報ｉｎｆ１や第２情報ｉｎｆ２を共有することや、各ノード間で第１情報ｉｎｆ１や第２情報ｉｎｆ２を授受することを要しない。従って、第１ノード１１０や第２ノード２１０の認証が実行される場合のセキュリティ上のリスクを低減でき、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とを適切に連携できる。
　また、例えば、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とを分散型取引所（ＤＥＸ：Decentralized Exchange）等の連携アプリケーションによって連携させる場合、ＤＥＸ等がセキュリティ上の弱点になり得る。本実施形態では、ＤＥＸ等を要しないため、このようなセキュリティリスクを抑制できる。また、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とを連携用の分散型ネットワークを介して連携させる場合、通常、第１分散型ネットワーク１０１および第２分散型ネットワーク２０１の規格を連携用の分散型ネットワークの規格に適合させることを要する。ブロックチェーンネットワークとして構成された連携用の分散型ネットワークは、リレーチェーンとも呼ばれる。本実施形態では、リレーチェーン等を要しないため、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とを簡易に連携できる。
　また、本実施形態では、第１分散型台帳ＤＬ１および第２分散型台帳ＤＬ２は、それぞれ、ブロックチェーンによって構成され、第１ウォレットＷ１への第１情報ｉｎｆ１の格納と、第１指定情報ｓｐ１の格納とは、それぞれ、第１分散型台帳ＤＬ１に追加されるブロックに格納されるトランザクションによって実現され、第２ウォレットＷ２への第２情報ｉｎｆ２の格納と、第２指定情報ｓｐ２の格納とは、それぞれ、第２分散型台帳ＤＬ２に追加されるブロックに格納されるトランザクションによって実現される。これによって、第１分散型ネットワーク１０１および第２分散型ネットワーク２０１を、それぞれ、ブロックチェーンネットワークとして構成できる。そのため、中央集権的な情報管理によるリスクをより低減できる。
　また、本実施形態では、第１指定情報ｓｐ１は、第１識別子と第２識別子との組み合わせによって第２ウォレットＷ２を指定し、第２指定情報ｓｐ２は、第３識別子と第４識別子との組み合わせによって第１ウォレットＷ１を指定する。第２制御部２１１は、第１要求に応じて、第１ノード１１０に第３識別子を送信することで、第１ウォレットＷ１を指定する。第１制御部１１１は、第２要求に応じて、第２ノード２１０に第１識別子を送信することで、第２ウォレットＷ２を指定する。そのため、各ノード間で第２識別子や第４識別子を授受することによって、簡易に第１認証や第２認証を要求できる。特に、第１認証や第２認証を要求する際に、第１識別子や第３識別子、または、第１識別子や第３識別子に相当する情報を各ノード間で授受しないようにすれば、仮に、第１認証の要求や第２認証の要求が第三者に傍受された場合であっても、認証の要求先が第三者に読み取られる可能性を低減できる。そのため、セキュリティ上のリスクをより低減できる。
　また、本実施形態では、第１ウォレットＷ１には、第１署名済みコードが第１非代替性トークンＴ１として格納され、第２ウォレットＷ２には、第２署名済みコードが第２非代替性トークンＴ２として格納される。第２制御部２１１は、第１要求を受けた場合、第１ノード１１０に第２署名済みコードを送信する。第１制御部１１１は、第１認証において、第１署名済みコードと第２署名済みコードとが対応するか否かを判定し、両コードが対応する場合、第２ノード２１０を認証する。そのため、第１非代替性トークンＴ１としての第１署名済みコードと、第２非代替性トークンＴ２としての第２署名済みコードとの対応性を検証することによって、簡易に第２ノード２１０を認証できる。
　また、本実施形態では、第１非代替性トークンＴ１として格納された第１署名済みコードには有効期限が設定され、第１制御部１１１は、第１認証において、有効期限が満了していない第１署名済みコードと第２署名済みコードとが対応するか否かを判定する。そのため、第１署名済みコードの有効期限が満了していない場合に第２ノード２１０を認証できるので、第１認証において、セキュリティ上のリスクをより抑制できる。
　また、本実施形態では、第１制御部１１１は、第２ノード２１０を認証した場合、第２ノード２１０に第１情報ｉｎｆ１を提供し、前記第１分散型台帳ＤＬ１に第１提供情報を記録する。そのため、第１分散型台帳ＤＬ１の耐改竄性を向上できる。
　また、本実施形態では、第１制御部１１１は、第２ノード２１０を認証した場合、第２ノード２１０に、第１データベース１９０から取得した第１情報ｉｎｆ１を提供し、第２制御部２１１は、第１ノード１１０を認証した場合、第１ノード１１０に、第２データベース２９０から取得した第２情報ｉｎｆ２を提供する。そのため、例えば、第２ノード２１０が第１情報ｉｎｆ１に直接アクセスする形態や、第１ノード１１０が第２情報ｉｎｆ２に直接アクセスする形態と比較して、セキュリティ上のリスクをより抑制できる。
　また、本実施形態では、第２制御部２１１は、第１要求が実行された場合、第１ローカル認証と第１公開鍵認証とが完了した後に、第１ノード１１０に第１認証を要求する。第１制御部１１１は、第２要求が実行された場合、第２ローカル認証と第２公開鍵認証とが完了した後に、第２ノード２１０に第２認証を要求する。そのため、各ノードがユーザ端末４００から第１要求や第２要求を受けた場合に、ローカル認証と公開鍵認証とを用いて適切にユーザ端末４００を認証した後で、各ノードの認証を要求できる。
Ｂ．第２実施形態：
　図１０は、第２実施形態における認証システム１０ｂを示す説明図である。認証システム１０ｂは、第１実施形態と異なり、第３ネットワークシステム３００を備える。認証システム１０ｂの構成のうち、特に説明しない部分については第１実施形態と同様である。
　第３ネットワークシステム３００は、複数の第３ノード３１０によって構成された第３分散型ネットワーク３０１を備える。第３分散型ネットワーク３０１は、認証システム１０ｂにおける他のネットワークやユーザ端末４００と同様に、インターネットＩＮＴに接続されている。第３ノード３１０は、第３分散型ネットワーク３０１からアクセス可能な第３データベース３９０に格納された、ユーザに関する第３情報ｉｎｆ３にアクセス可能に構成されている。各第３ノード３１０は、ブロックチェーンによって構成された第３分散型台帳を共有している。第３ノード３１０は、第１制御部１１１と同様にコンピュータによって構成された第３制御部３１１を備える。
　本実施形態では、第２ウォレットＷ２には、第２指定情報ｓｐ２に加え、第３分散型台帳の第３ウォレットＷ３を指定する第３指定情報ｓｐ３が、非代替性を有する第７非代替性トークンＴ７として格納されている。第３指定情報ｓｐ３は、例えば、第１指定情報ｓｐ１や第２指定情報ｓｐ２と同様に、多階層登録型のデータ構造によって表される。第３ウォレットＷ３には、第３情報ｉｎｆ３のＵＲＩと、第１指定情報ｓｐ１とが格納されている。第３ウォレットＷ３において、第１指定情報ｓｐ１は、非代替性を有する第８非代替性トークンＴ８として格納されている。これにより、本実施形態では、第２分散型ネットワーク２０１と第３分散型ネットワーク３０１とは、第１分散型ネットワーク１０１と第２分散型ネットワーク２０１とが連携状態にあるのと同様に、連携状態にある。第２分散型ネットワーク２０１と第３分散型ネットワーク３０１との連携は、例えば、図５の連携処理と同様の処理が、ユーザ端末４００と第２ノード２１０と第３ノード３１０との間で実行されることによって実現される。
　認証システム１０ｂでは、第１ウォレットＷ１には第３指定情報ｓｐ３が格納されていないが、第１制御部１１１は、第２ノード２１０を介して第３情報ｉｎｆ３を取得できる。より詳細には、例えば、第１制御部１１１は、第１指定情報ｓｐ１を用いて第２ノード２１０に第１ノード１１０を認証させた後に、第２制御部２１１から第３ノード３１０に、第２ウォレットＷ２に格納された第３指定情報ｓｐ３を用いて第２ノード２１０の認証を要求させる。第３ノード３１０による第２ノード２１０の認証は、例えば、図６および図７に示した第１認証処理と同様の処理が、ユーザ端末４００と第２ノード２１０と第３ノード３１０との間で実行されることによって実現される。第３ノード３１０によって第２ノード２１０が認証された場合、第２制御部２１１は、例えば、第３ノード３１０から第３情報ｉｎｆ３を取得する。これによって、第１制御部１１１は、第２制御部２１１によって取得された第３情報ｉｎｆ３を取得できる。上記と同様に、第３制御部３１１は、第２ノード２１０を介して第１情報ｉｎｆ１を取得してもよい。この場合、第２ノード２１０による第３ノード３１０の認証は、例えば、図８および図９に示した第２認証処理と同様の処理が、ユーザ端末４００と第２ノード２１０と第３ノード３１０との間で実行されることによって実現される。
　このようにすれば、第１ウォレットＷ１や第３ウォレットＷ３に格納されるデータ数を削減しつつ、第１分散型ネットワーク１０１と第３分散型ネットワーク３０１とを連携できる。また、第１ウォレットＷ１に格納された情報からは、第１ウォレットＷ１と第３ウォレットＷ３とが関連付けられていること自体が読み取られないため、セキュリティ上のリスクをより低減できる。なお、他の実施形態では、認証システム１０ｂは、例えば、４以上の分散型ネットワークを備えていてもよい。
Ｃ．第３実施形態：
　図１１は、第３実施形態における認証システム１０ｃを示す説明図である。認証システム１０ｃは、第１実施形態と異なり、第４ネットワークシステム５００を備える。認証システム１０ｃの構成のうち、特に説明しない部分については第１実施形態と同様である。
　第４ネットワークシステム５００は、分散型ではないネットワーク５０１を備える。ネットワーク５０１は、端末装置５１０を含む複数のノードＮｄによって構成されている。ネットワーク５０１は、認証システム１０ｃにおける他のネットワークやユーザ端末４００と同様にインターネットＩＮＴに接続されている。本実施形態では、第４ネットワークシステム５００は、医療機関における中央集権型のネットワークとして構成されている。
　端末装置５１０は、第４制御部５１１を備える。第４制御部５１１は、第１制御部１１１と同様にコンピュータによって構成され、ＣＰＵと記憶部５１２と入出力インターフェイスとを備える。端末装置５１０は、ユーザ端末４００を使用するユーザに関する第４情報ｉｎｆ４にアクセス可能に構成されている。本実施形態では、第４情報ｉｎｆ４は、医療機関における患者の識別番号としてユーザに付与されたＩＤであり、記憶部５１２内のデータベースＤＢに格納されている。
　本実施形態では、記憶部５１２内のデータベースＤＢには、データベースＤＢで一意のアドレスＡｄを主キーとして、第４情報ｉｎｆ４のＵＲＩと第１指定情報ｓｐ１とが格納されている。第２ウォレットＷ２には、第２指定情報ｓｐ２に加え、第４指定情報ｓｐ４が、非代替性を有する第９非代替性トークンＴ９として格納されている。第４指定情報ｓｐ４は、端末装置５１０を表す第５識別子と、データベースＤＢで一意の第６識別子との組み合わせによって、データベースＤＢにおけるアドレスＡｄを主キーとするレコードを指定する。第４指定情報ｓｐ４は、図１１において、「第５識別子：第６識別子」の形式で表されている。本実施形態では、第５識別子は、端末装置５１０のＵＲＮであり、図３において「ＴＥ」と表されている。第６識別子は、アドレスＡｄである。
　本実施形態では、上記のように第２ウォレットＷ２に第４指定情報ｓｐ４が格納され、かつ、データベースＤＢにアドレスＡｄを主キーとして第１指定情報ｓｐ１が格納されていることにより、ネットワーク５０１と第２分散型ネットワーク２０１とは、連携状態にある。ネットワーク５０１と第２分散型ネットワーク２０１との連携は、例えば、図５の連携処理と同様の処理が、ユーザ端末４００と第２ノード２１０と端末装置５１０との間で実行されることによって実現される。この場合、図５のステップＳ２２８に相当する処理では、第４制御部５１１は、署名済みのチャレンジコードとアドレスＡｄとを第２ノード２１０に送信する。また、ステップＳ２３６に相当する処理では、第４制御部５１１は、記憶部５１２に、アドレスＡｄを主キーとして、第４情報ｉｎｆ４のＵＲＩや第１指定情報ｓｐ１を格納する。
　本実施形態では、第４制御部５１１は、ユーザ端末制御部４０１からの要求に応じて、第１指定情報ｓｐ１を用いて、第２ノード２１０に、第９非代替性トークンＴ９に基づいて端末装置５１０を認証させることを要求できる。第２ノード２１０による端末装置５１０の認証は、例えば、図６および図７に示した第１認証処理と同様の処理が、ユーザ端末４００と第２ノード２１０と端末装置５１０との間で実行されることによって実現される。これによって、第４制御部５１１は、例えば、第２ノード２１０から第２情報ｉｎｆ２を取得できる。同様に、第２制御部２１１が、第４指定情報ｓｐ４を用いて、端末装置５１０に、アドレスＡｄを主キーとして格納された第１指定情報ｓｐ１に基づいて第２ノード２１０を認証させることを要求してもよい。この場合、端末装置５１０による第２ノード２１０の認証は、例えば、図８および図９に示した第２認証処理と同様の処理が、ユーザ端末４００と第２ノード２１０と端末装置５１０との間で実行されることによって実現される。また、第４制御部５１１は、例えば、第３実施形態で説明したのと同様に、第２ノード２１０を介して第１情報ｉｎｆ１を取得してもよい。同様に、第１制御部１１１は、第２ノード２１０を介して第４情報ｉｎｆ４を取得してもよい。
　他の実施形態では、例えば、第１分散型ネットワーク１０１と非分散型のネットワークとが連携状態にあってもよいし、１つの分散型ネットワークと２以上の非分散型のネットワークとが連携状態にあってもよい。
Ｄ．他の実施形態：
（Ｄ１）上記実施形態では、第１ネットワークシステム１００は、個人番号の管理システムとして構成され、第２ネットワークシステム２００は、医療データの管理システムとして構成されている。これに対して、各ネットワークシステムが、このように構成されていなくてもよい。例えば、第１ネットワークシステム１００が医療データの管理システムとして構成され、第２ネットワークシステム２００が個人番号の管理システムとして構成されてもよい。また、各ネットワークシステムが、例えば、金融データを管理するシステム等の他のシステムとして構成されてもよい。また、各ネットワークシステムが、例えば、いわゆるメタバース等の仮想空間サービスを提供するシステムとして構成されてもよい。この場合、第１情報ｉｎｆ１や第２情報ｉｎｆ２は、例えば、仮想空間上でユーザによって所有されたアイテムを表すデータであってもよい。
（Ｄ２）上記実施形態では、第１分散型台帳ＤＬ１および第２分散型台帳ＤＬ２は、ブロックチェーンによって構成されている。これに対して、第１分散型台帳ＤＬ１や第２分散型台帳ＤＬ２は、ブロックチェーンによって構成されなくてもよく、他の方式の分散型台帳として構成されてもよい。この場合、第１分散型台帳ＤＬ１や第２分散型台帳ＤＬ２は、有向非巡回グラフや、ハッシュグラフ、ホロチェーン等によって構成されてもよい。
（Ｄ３）上記実施形態では、第１指定情報ｓｐ１は、第１識別子と第２識別子とを含んでいるが、第１識別子と第２識別子とを含んでいなくてもよい。例えば、第１指定情報ｓｐ１は、「分散型台帳のウォレット」自体を一意に表す１の識別子によって表されてもよい。同様に、第２指定情報ｓｐ２は、第３識別子と第４識別子とを含んでいなくてもよい。
（Ｄ４）上記実施形態では、第１制御部１１１は、第１認証において、第１署名済みコードと第２署名済みコードとが対応するか否かを判定し、両コードが対応する場合に第２ノード２１０を認証している。これに対して、第１制御部１１１は、第１認証において、このように第２ノード２１０を認証しなくてもよく、例えば、第２制御部２１１から送信された第２ウォレットアドレスＷＡ２と、第１ウォレットＷ１に第１非代替性トークンＴ１として格納された第１指定情報ｓｐ１とが対応するか否かを検証し、対応する場合に第２ノード２１０を認証してもよい。同様に、第２制御部２１１は、第２認証において、第１署名済みコードと第２署名済みコードとが対応するか否かを判定しなくてもよい。
（Ｄ５）上記実施形態では、更に、第２非代替性トークンＴ２として格納された第２署名済みコードや、第４非代替性トークンＴ４として格納された署名済みコードｃｃ５２ｓに有効期限が設定されてもよい。また、第１非代替性トークンＴ１として格納された第１署名済みコードや、第３非代替性トークンＴ３として格納された署名済みコードｃｃ５１ｓに有効期限が設定されなくてもよい。この場合、各署名済みコードに単に有効期限が設定されなくてもよい。また、例えば、図５のステップＳ２３２で、第１ウォレットＷ１の階層ＩＤａ１に署名データとしてヌル値を格納してもよい。この場合、トランザクションＴＸ１２には、格納データ情報として、ヌル値の署名データが記述される。これによって、図６の第１認証処理において、ステップＳ３１６で署名済みコードが対応しないため、図７に示した新たなチャレンジコードを用いた署名の検証を経た後に、第１ノード１１０によって第２ノード２１０を認証できる。そのため、第１認証におけるセキュリティ上のリスクをより低減できる。同様に、例えば、図７のステップＳ３４０で第１ウォレットＷ１の階層ＩＤａ２に署名データとしてヌル値を格納してもよい。
（Ｄ６）上記実施形態では、第１制御部１１１は、第１分散型台帳ＤＬ１に、第１提供情報ＰＲ１を記録しているが、第１提供情報ＰＲ１を記録しなくてもよい。同様に、第２制御部２１１は、第２分散型台帳ＤＬ２に第２提供情報を記録しなくてもよい。
（Ｄ７）上記実施形態では、第１制御部１１１は、第２ノード２１０を認証した場合、第２ノード２１０に対して、第１データベース１９０から取得した第１情報ｉｎｆ１を提供している。これに対して、第１制御部１１１は、このように第１情報ｉｎｆ１を提供しなくてもよい。例えば、第１制御部１１１は、第２ノード２１０を認証した場合、第２ノード２１０に対して、第１データベース１９０上の第１情報ｉｎｆ１にアクセスすることを許可してもよい。このアクセス許可は、一時的であってもよい。同様に、第２制御部２１１は、第１ノード１１０を認証した場合、第１ノード１１０に対して、第２データベース２９０から取得した第２情報ｉｎｆ２を提供しなくてもよい。
（Ｄ８）上記実施形態では、第１制御部１１１や第２制御部２１１は、ＦＩＤＯ認証が完了した後に第２認証や第１認証を要求しているが、ＦＩＤＯ認証を実行しなくてもよい。例えば、第１制御部１１１や第２制御部２１１は、パスワード認証によってユーザ端末制御部４０１を認証した後に、第２認証や第１認証を要求してもよい。
１０，１０ｂ，１０ｃ…認証システム、１００…第１ネットワークシステム、１０１…第１分散型ネットワーク、１１０…第１ノード、１１１…第１制御部、１９０…第１データベース、２００…第２ネットワークシステム、２０１…第２分散型ネットワーク、２１０…第２ノード、２１１…第２制御部、２９０…第２データベース、３００…第３ネットワークシステム、３０１…第３分散型ネットワーク、３１０…第３ノード、３１１…第３制御部、３９０…第３データベース、４００…ユーザ端末、４０１…ユーザ端末制御部、４０３…記憶部、４０４…プログラム、４１０…表示部、５００…第４ネットワークシステム、５０１…ネットワーク、５１０…端末装置、５１１…第４制御部、５１２…記憶部

Claims (11)

  1. 　第１分散型台帳を共有し、ユーザに関する第１情報にアクセス可能な複数の第１ノードによって構成された第１分散型ネットワークと、
    　第２分散型台帳を共有し、前記ユーザに関する第２情報にアクセス可能な複数の第２ノードによって構成された第２分散型ネットワークと、
    　前記ユーザによって使用され、ユーザ端末制御部を有するユーザ端末と、を備え、
    　前記第１ノードは、第１制御部を有し、
    　前記第２ノードは、第２制御部を有し、
    　前記第１分散型台帳の第１ウォレットには、前記第１情報のＵＲＩと、前記第２分散型台帳の第２ウォレットを指定する第１指定情報と、が格納され、前記第１指定情報は、非代替性を有するトークンである第１非代替性トークンとして格納され、
    　前記第２分散型台帳の前記第２ウォレットには、前記第２情報のＵＲＩと、前記第１ウォレットを指定する第２指定情報と、が格納され、前記第２指定情報は、非代替性を有するトークンである第２非代替性トークンとして格納され、
    　前記第２制御部は、前記ユーザ端末制御部からの第１要求に応じて、前記第２指定情報を用いて前記第１ウォレットを指定することで、前記第１ノードに、前記第１非代替性トークンに基づいて前記ユーザのために前記第２ノードを認証する第１認証を要求し、
    　前記第１制御部は、前記ユーザ端末制御部からの第２要求に応じて、前記第１指定情報を用いて前記第２ウォレットを指定することで、前記第２ノードに、前記第２非代替性トークンに基づいて前記ユーザのために前記第１ノードを認証する第２認証を要求する、認証システム。
  2. 　請求項１に記載の認証システムであって、
    　前記第１分散型台帳および前記第２分散型台帳は、それぞれ、ブロックチェーンによって構成され、
    　前記第１ウォレットへの前記第１情報のＵＲＩの格納と、前記第１指定情報の格納とは、それぞれ、前記第１分散型台帳に追加されるブロックに格納されるトランザクションによって実現され、
    　前記第２ウォレットへの前記第２情報のＵＲＩの記録と、前記第２指定情報の記録とは、それぞれ、前記第２分散型台帳に追加されるブロックに格納されるトランザクションによって実現される、認証システム。
  3. 　請求項１に記載の認証システムであって、
    　前記第１指定情報は、前記第２分散型ネットワークを表す第１識別子と、前記第２分散型台帳において一意の第２識別子とを含み、前記第１識別子と前記第２識別子との組み合わせによって前記第２ウォレットを指定し、
    　前記第２指定情報は、前記第１分散型ネットワークを表す第３識別子と、前記第１分散型台帳において一意の第４識別子とを含み、前記第３識別子と前記第４識別子との組み合わせによって前記第１ウォレットを指定し、
    　前記第２制御部は、前記第１要求に応じて、前記第１ノードに前記第３識別子を送信することによって、前記第１ウォレットを指定し、
    　前記第１制御部は、前記第２要求に応じて、前記第２ノードに前記第２識別子を送信することによって、前記第２ウォレットを指定する、認証システム。
  4. 　請求項１に記載の認証システムであって、
    　前記第１ウォレットには、前記ユーザ端末の秘密鍵を用いて署名済みの第１認証コードである第１署名済みコードが、前記第１非代替性トークンとして格納され、
    　前記第２ウォレットには、前記秘密鍵を用いて署名済みの、前記第１認証コードと対応する第２認証コードである、第２署名済みコードが、前記第２非代替性トークンとして格納され、
    　前記第２制御部は、前記第１要求が実行された場合、前記第１ノードに前記第２署名済みコードを送信し、
    　前記第１制御部は、前記第１認証が要求された場合、前記第１署名済みコードと前記第２署名済みコードとが対応するか否かを判定し、前記第１署名済みコードと前記第２署名済みコードとが対応する場合、前記第２ノードを認証する、認証システム。
  5. 　請求項４に記載の認証システムであって、
    　前記第１非代替性トークンとして格納された前記第１署名済みコードには、有効期限が設定され、
    　前記第１制御部は、前記第１認証が要求された場合、前記有効期限が満了していない前記第１署名済みコードと前記第２署名済みコードとが対応するか否かを判定する、認証システム。
  6. 　請求項１に記載の認証システムであって、
    　前記第１制御部は、前記第２ノードを認証した場合、前記第２ノードに前記第１情報を提供し、前記第１分散型台帳に、前記第２ノードに前記第１情報を提供したこと表す情報を記録する、認証システム。
  7. 　請求項１に記載の認証システムであって、
    　前記第１情報は、前記第１分散型ネットワークからアクセス可能な第１データベースに格納され、
    　前記第２情報は、前記第２分散型ネットワークからアクセス可能な第２データベースに格納され、
    　前記第１制御部は、前記第２ノードを認証した場合、前記第２ノードに、前記第１データベースから取得した前記第１情報を提供し、
    　前記第２制御部は、前記第１ノードを認証した場合、前記第１ノードに、前記第２データベースから取得した前記第２情報を提供する、認証システム。
  8. 　請求項１から７のいずれか一項に記載の認証システムであって、
    　前記第２制御部は、前記第１要求が実行された場合、前記ユーザ端末による前記ユーザの第１ローカル認証と、前記第１ローカル認証の後に前記第２制御部によって実行される前記ユーザ端末の第１公開鍵認証と、が完了した後に、前記第１ノードに前記第１認証を要求し、
    　前記第１制御部は、前記第２要求が実行された場合、前記ユーザ端末による前記ユーザの第２ローカル認証と、前記第２ローカル認証の後に前記第１制御部によって実行される前記ユーザ端末の第２公開鍵認証と、が完了した後に、前記第２ノードに前記第２認証を要求する、認証システム。
  9. 　ユーザによって使用されるユーザ端末であって、
    　ユーザ端末制御部を備え、
    　前記ユーザ端末制御部は、
    　　第１分散型台帳を共有する複数のノードによって構成された第１分散型ネットワークに属し、前記ユーザに関する第１情報にアクセス可能な第１ノードに対して、第２要求を実行することが可能に構成され、
    　　第２分散型台帳を共有する複数のノードによって構成された第２分散型ネットワークに属し、前記ユーザに関する第２情報にアクセス可能な第２ノードに対して、第１要求を実行することが可能に構成され、
    　前記第１分散型台帳の第１ウォレットには、前記第１情報のＵＲＩと、前記第２分散型台帳の第２ウォレットを指定する第１指定情報と、が格納され、前記第１指定情報は、非代替性を有するトークンである第１非代替性トークンとして格納され、
    　前記第２分散型台帳の前記第２ウォレットには、前記第２情報のＵＲＩと、前記第１ウォレットを指定する第２指定情報と、が格納され、前記第２指定情報は、非代替性を有するトークンである第２非代替性トークンとして格納され、
    　前記第１要求が実行された場合、前記第２ノードの第２制御部は、前記第２指定情報を用いて前記第１ウォレットを指定することで、前記第１ノードに、前記第１非代替性トークンに基づいて前記ユーザのために前記第２ノードを認証する第１認証を要求し、
    　前記第２要求が実行された場合、前記第１ノードの第１制御部は、前記第１指定情報を用いて前記第２ウォレットを指定することで、前記第２ノードに、前記第２非代替性トークンに基づいて前記ユーザのために前記第１ノードを認証する第２認証を要求する、ユーザ端末。
  10. 　第１分散型ネットワークを構成する複数のノードによって共有された第１分散型台帳の第１ウォレットに、ユーザに関する第１情報のＵＲＩを格納する工程と、
    　前記第１ウォレットに、第２分散型ネットワークを構成する複数のノードによって共有された第２分散型台帳の第２ウォレットを指定する第１指定情報を、第１非代替性トークンとして格納する工程と、
    　前記第２ウォレットに、前記ユーザに関する第２情報のＵＲＩを格納する工程と、
    　前記第２ウォレットに、前記第１ウォレットを指定する第２指定情報を、第２非代替性トークンとして格納する工程と、
    　前記第２指定情報を用いて前記第１ウォレットを指定することで、前記第１分散型ネットワークに属し、前記第１情報にアクセス可能な第１ノードに対して、前記第１非代替性トークンに基づいて、前記ユーザのために、前記第２分散型ネットワークに属し前記第２情報にアクセス可能な第２ノードを認証することを要求する工程と、
    　前記第２ノードに対して、前記第１指定情報を用いて前記第２ウォレットを指定することで、前記第２非代替性トークンに基づいて前記ユーザのために前記第１ノードを認証することを要求する工程と、を備える、認証方法。
  11. 　ユーザによって使用されるユーザ端末を制御するコンピュータが実行するプログラムであって、
    　前記コンピュータに、
    　　第１分散型台帳を共有する複数のノードによって構成された第１分散型ネットワークに属し、前記ユーザに関する第１情報にアクセス可能な第１ノードに対する第１要求を実行させる機能と、
    　　第２分散型台帳を共有する複数のノードによって構成された第２分散型ネットワークに属し、前記ユーザに関する第２情報にアクセス可能な第２ノードに対する第２要求を実行させる機能と、を実現させ、
    　　前記第１分散型台帳の第１ウォレットには、前記第１情報のＵＲＩと、前記第２分散型台帳の第２ウォレットを指定する第１指定情報と、が格納され、前記第１指定情報は、非代替性を有するトークンである第１非代替性トークンとして格納され、
    　　前記第２分散型台帳の前記第２ウォレットには、前記第２情報のＵＲＩと、前記第１ウォレットを指定する第２指定情報と、が格納され、前記第２指定情報は、非代替性を有するトークンである第２非代替性トークンとして格納され、
    　前記第１要求が実行された場合、前記第２ノードの第２制御部は、前記第２指定情報を用いて前記第１ウォレットを指定することで、前記第１ノードに、前記第１非代替性トークンに基づいて前記ユーザのために前記第２ノードを認証する第１認証を要求し
    　前記第２要求が実行された場合、前記第１ノードの第１制御部は、前記第１指定情報を用いて前記第２ウォレットを指定することで、前記第２ノードに、前記第２非代替性トークンに基づいて前記ユーザのために前記第１ノードを認証する第２認証を要求する、プログラム。
PCT/JP2023/029831 2022-09-29 2023-08-18 認証システム、ユーザ端末、認証方法、および、プログラム WO2024070315A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022156298A JP7440590B1 (ja) 2022-09-29 2022-09-29 認証システム、ユーザ端末、認証方法、および、プログラム
JP2022-156298 2022-09-29

Publications (1)

Publication Number Publication Date
WO2024070315A1 true WO2024070315A1 (ja) 2024-04-04

Family

ID=90011253

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/029831 WO2024070315A1 (ja) 2022-09-29 2023-08-18 認証システム、ユーザ端末、認証方法、および、プログラム

Country Status (2)

Country Link
JP (2) JP7440590B1 (ja)
WO (1) WO2024070315A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020507143A (ja) 2017-12-21 2020-03-05 株式会社ＢａａＳｉｄ Ｌａｂ Ｊａｐａｎ ブロックチェーンを用いた一回性のアクセス権限付与システム
US20210133700A1 (en) * 2019-10-10 2021-05-06 Forte Labs, Inc. Blockchain Cross-Chain Non-Fungible Token Exchange
JP7029212B1 (ja) * 2021-10-29 2022-03-03 充宏 前田 取引支援システム、取引支援方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020507143A (ja) 2017-12-21 2020-03-05 株式会社ＢａａＳｉｄ Ｌａｂ Ｊａｐａｎ ブロックチェーンを用いた一回性のアクセス権限付与システム
US20210133700A1 (en) * 2019-10-10 2021-05-06 Forte Labs, Inc. Blockchain Cross-Chain Non-Fungible Token Exchange
JP7029212B1 (ja) * 2021-10-29 2022-03-03 充宏 前田 取引支援システム、取引支援方法及びプログラム

Also Published As

Publication number Publication date
JP2024050917A (ja) 2024-04-10
JP2024049829A (ja) 2024-04-10
JP7440590B1 (ja) 2024-02-28

Similar Documents

Publication Publication Date Title
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
Lesavre et al. A taxonomic approach to understanding emerging blockchain identity management systems
US11362842B2 (en) Membership compiler for applications
JP7462903B2 (ja) 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム
US20210306135A1 (en) Electronic device within blockchain based pki domain, electronic device within certification authority based pki domain, and cryptographic communication system including these electronic devices
CN113255014B (zh) 一种基于区块链的数据处理方法以及相关设备
TW202223793A (zh) 驗證系統及方法
TW202217610A (zh) 鑑認系統及方法
TW202131659A (zh) 用以儲存已認證資料於區塊鏈上之電腦實行方法及系統
JP2023543470A (ja) 物理複製困難関数に基づくチャレンジ応答プロトコル
TWI818209B (zh) 基於分散式分類帳之憑證鑑別及憑證發布之方法及系統
TW202230397A (zh) 實體不可仿製之功能
TW202215814A (zh) 實體不可仿製之功能
WO2024070315A1 (ja) 認証システム、ユーザ端末、認証方法、および、プログラム
CN116975810A (zh) 身份验证方法、装置、电子设备及计算机可读存储介质
KR102343461B1 (ko) 스마트 컨트랙트의 외부 IoT 데이터 공급 방법 및 이를 위한 오라클 시스템
TW202215815A (zh) 實體不可仿製之功能
JP2024151902A (ja) 情報処理システム、ユーザ端末、情報処理方法、および、プログラム
CN113468600B (zh) 一种数据授权方法、装置和设备
Matsuo et al. On universal composable security of time-stamping protocols
Pärni On Self-Sovereign Identity: Verifiable Credentials and Presentations with OpenID Connect
Lv et al. Reinventing Multi-User Authentication Security from Cross-Chain Perspective
Kumar et al. LandChain: A MultiChain Based Novel Secure Land Record Transfer System
GB2612769A (en) Authenticating a device
TW202205834A (zh) 電腦實施系統及方法

Legal Events

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

Ref document number: 23871557

Country of ref document: EP

Kind code of ref document: A1