WO2024070315A1 - 認証システム、ユーザ端末、認証方法、および、プログラム - Google Patents
認証システム、ユーザ端末、認証方法、および、プログラム Download PDFInfo
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- 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
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
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)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
このような形態によれば、第1指定情報を用いて第2ウォレットを指定することによって第1ノードの認証を要求でき、第2指定情報を用いて第1ウォレットを指定することによって第2ノードの認証を要求できる。そのため、各ノードが認証を要求する場合に、各ノードが第1情報や第2情報を共有することや、各ノード間で第1情報や第2情報を授受することを要しない。従って、第1ノードや第2ノードの認証が実行される場合のセキュリティ上のリスクを低減でき、第1分散型ネットワークと第2分散型ネットワークとを適切に連携できる。
(2)上記形態において、前記第1分散型台帳および前記第2分散型台帳は、それぞれ、ブロックチェーンによって構成され、前記第1ウォレットへの前記第1情報のURIの格納と、前記第1指定情報の格納とは、それぞれ、前記第1分散型台帳に追加されるブロックに格納されるトランザクションによって実現され、前記第2ウォレットへの前記第2情報のURIの記録と、前記第2指定情報の記録とは、それぞれ、前記第2分散型台帳に追加されるブロックに格納されるトランザクションによって実現されてもよい。このような形態によれば、第1分散型ネットワークおよび第2分散型ネットワークを、それぞれ、ブロックチェーンネットワークとして構成できる。そのため、中央集権的な情報管理によるリスクをより低減できる。
(3)上記形態において、前記第1指定情報は、前記第2分散型ネットワークを表す第1識別子と、前記第2分散型台帳において一意の第2識別子とを含み、前記第1識別子と前記第2識別子との組み合わせによって前記第2ウォレットを指定し、前記第2指定情報は、前記第1分散型ネットワークを表す第3識別子と、前記第1分散型台帳において一意の第4識別子とを含み、前記第3識別子と前記第4識別子との組み合わせによって前記第1ウォレットを指定し、前記第2制御部は、前記第1要求に応じて、前記第1ノードに前記第3識別子を送信することによって、前記第1ウォレットを指定し、前記第1制御部は、前記第2要求に応じて、前記第2ノードに前記第2識別子を送信することによって、前記第2ウォレットを指定してもよい。このような形態によれば、各ノード間で第2識別子や第4識別子を授受することによって、簡易に各ノードの認証を要求できる。
(4)上記形態において、前記第1ウォレットには、前記ユーザ端末の秘密鍵を用いて署名済みの第1認証コードである第1署名済みコードが、前記第1非代替性トークンとして格納され、前記第2ウォレットには、前記秘密鍵を用いて署名済みの、前記第1認証コードと対応する第2認証コードである、第2署名済みコードが、前記第2非代替性トークンとして格納され、前記第2制御部は、前記第1要求が実行された場合、前記第1ノードに前記第2署名済みコードを送信し、前記第1制御部は、前記第1認証が要求された場合、前記第1署名済みコードと前記第2署名済みコードとが対応するか否かを判定し、前記第1署名済みコードと前記第2署名済みコードとが対応する場合、前記第2ノードを認証してもよい。このような形態によれば、第1非代替性トークンとしての第1署名済みコードと、第2非代替性トークンとしての第2署名済みコードとの対応性を検証することによって、簡易に第2ノードを認証できる。
(5)上記形態において、前記第1非代替性トークンとして格納された前記第1署名済みコードには、有効期限が設定され、前記第1制御部は、前記第1認証が要求された場合、前記有効期限が満了していない前記第1署名済みコードと前記第2署名済みコードとが対応するか否かを判定してもよい。このような形態によれば、第1署名済みコードの有効期限が満了していない場合に第2ノードを認証できるので、第1認証において、セキュリティ上のリスクをより抑制できる。
(6)上記形態において、前記第1制御部は、前記第2ノードを認証した場合、前記第2ノードに前記第1情報を提供し、前記第1分散型台帳に、前記第2ノードに前記第1情報を提供したことを表す情報を記録してもよい。このような形態によれば、第1分散型台帳の耐改竄性を向上できる。
(7)上記形態において、前記第1情報は、前記第1分散型ネットワークから参照可能な第1データベースに格納され、前記第2情報は、前記第2分散型ネットワークから参照可能な第2データベースに格納され、前記第1制御部は、前記第2ノードを認証した場合、前記第2ノードに対して、前記第1データベースから取得した前記第1情報を提供し、前記第2制御部は、前記第1ノードを認証した場合、前記第1ノードに対して、前記第2データベースから取得した前記第2情報を提供してもよい。このような形態によれば、例えば、第2ノードが第1情報に直接アクセスする形態や、第1ノードが第2情報に直接アクセスする形態と比較して、セキュリティ上のリスクをより抑制できる。
(8)上記形態において、前記第2制御部は、前記第1要求が実行された場合、前記ユーザ端末による前記ユーザの第1ローカル認証と、前記第1ローカル認証の後に前記第2制御部によって実行される前記ユーザ端末の第1公開鍵認証と、が完了した後に、前記第1ノードに前記第1認証を要求し、前記第1制御部は、前記第2要求が実行された場合、前記ユーザ端末による前記ユーザの第2ローカル認証と、前記第2ローカル認証の後に前記第1制御部によって実行される前記ユーザ端末の第2公開鍵認証と、が完了した後に、前記第2ノードに前記第1認証を要求してもよい。このような形態によれば、各ノードがユーザ端末から第1要求や第2要求を受けた場合に、ローカル認証と公開鍵認証とを用いて適切にユーザ端末を認証した後で、各ノードの認証を要求できる。
図1は、本実施形態における認証システム10を示す説明図である。認証システム10は、第1ネットワークシステム100と、第2ネットワークシステム200と、ユーザ端末400とを備える。ネットワークシステム同士、および、各ネットワークシステムとユーザ端末400とは、インターネットINTを介して相互に通信可能に構成されている。
図10は、第2実施形態における認証システム10bを示す説明図である。認証システム10bは、第1実施形態と異なり、第3ネットワークシステム300を備える。認証システム10bの構成のうち、特に説明しない部分については第1実施形態と同様である。
図11は、第3実施形態における認証システム10cを示す説明図である。認証システム10cは、第1実施形態と異なり、第4ネットワークシステム500を備える。認証システム10cの構成のうち、特に説明しない部分については第1実施形態と同様である。
(D1)上記実施形態では、第1ネットワークシステム100は、個人番号の管理システムとして構成され、第2ネットワークシステム200は、医療データの管理システムとして構成されている。これに対して、各ネットワークシステムが、このように構成されていなくてもよい。例えば、第1ネットワークシステム100が医療データの管理システムとして構成され、第2ネットワークシステム200が個人番号の管理システムとして構成されてもよい。また、各ネットワークシステムが、例えば、金融データを管理するシステム等の他のシステムとして構成されてもよい。また、各ネットワークシステムが、例えば、いわゆるメタバース等の仮想空間サービスを提供するシステムとして構成されてもよい。この場合、第1情報inf1や第2情報inf2は、例えば、仮想空間上でユーザによって所有されたアイテムを表すデータであってもよい。
Claims (11)
- 第1分散型台帳を共有し、ユーザに関する第1情報にアクセス可能な複数の第1ノードによって構成された第1分散型ネットワークと、
第2分散型台帳を共有し、前記ユーザに関する第2情報にアクセス可能な複数の第2ノードによって構成された第2分散型ネットワークと、
前記ユーザによって使用され、ユーザ端末制御部を有するユーザ端末と、を備え、
前記第1ノードは、第1制御部を有し、
前記第2ノードは、第2制御部を有し、
前記第1分散型台帳の第1ウォレットには、前記第1情報のURIと、前記第2分散型台帳の第2ウォレットを指定する第1指定情報と、が格納され、前記第1指定情報は、非代替性を有するトークンである第1非代替性トークンとして格納され、
前記第2分散型台帳の前記第2ウォレットには、前記第2情報のURIと、前記第1ウォレットを指定する第2指定情報と、が格納され、前記第2指定情報は、非代替性を有するトークンである第2非代替性トークンとして格納され、
前記第2制御部は、前記ユーザ端末制御部からの第1要求に応じて、前記第2指定情報を用いて前記第1ウォレットを指定することで、前記第1ノードに、前記第1非代替性トークンに基づいて前記ユーザのために前記第2ノードを認証する第1認証を要求し、
前記第1制御部は、前記ユーザ端末制御部からの第2要求に応じて、前記第1指定情報を用いて前記第2ウォレットを指定することで、前記第2ノードに、前記第2非代替性トークンに基づいて前記ユーザのために前記第1ノードを認証する第2認証を要求する、認証システム。 - 請求項1に記載の認証システムであって、
前記第1分散型台帳および前記第2分散型台帳は、それぞれ、ブロックチェーンによって構成され、
前記第1ウォレットへの前記第1情報のURIの格納と、前記第1指定情報の格納とは、それぞれ、前記第1分散型台帳に追加されるブロックに格納されるトランザクションによって実現され、
前記第2ウォレットへの前記第2情報のURIの記録と、前記第2指定情報の記録とは、それぞれ、前記第2分散型台帳に追加されるブロックに格納されるトランザクションによって実現される、認証システム。 - 請求項1に記載の認証システムであって、
前記第1指定情報は、前記第2分散型ネットワークを表す第1識別子と、前記第2分散型台帳において一意の第2識別子とを含み、前記第1識別子と前記第2識別子との組み合わせによって前記第2ウォレットを指定し、
前記第2指定情報は、前記第1分散型ネットワークを表す第3識別子と、前記第1分散型台帳において一意の第4識別子とを含み、前記第3識別子と前記第4識別子との組み合わせによって前記第1ウォレットを指定し、
前記第2制御部は、前記第1要求に応じて、前記第1ノードに前記第3識別子を送信することによって、前記第1ウォレットを指定し、
前記第1制御部は、前記第2要求に応じて、前記第2ノードに前記第2識別子を送信することによって、前記第2ウォレットを指定する、認証システム。 - 請求項1に記載の認証システムであって、
前記第1ウォレットには、前記ユーザ端末の秘密鍵を用いて署名済みの第1認証コードである第1署名済みコードが、前記第1非代替性トークンとして格納され、
前記第2ウォレットには、前記秘密鍵を用いて署名済みの、前記第1認証コードと対応する第2認証コードである、第2署名済みコードが、前記第2非代替性トークンとして格納され、
前記第2制御部は、前記第1要求が実行された場合、前記第1ノードに前記第2署名済みコードを送信し、
前記第1制御部は、前記第1認証が要求された場合、前記第1署名済みコードと前記第2署名済みコードとが対応するか否かを判定し、前記第1署名済みコードと前記第2署名済みコードとが対応する場合、前記第2ノードを認証する、認証システム。 - 請求項4に記載の認証システムであって、
前記第1非代替性トークンとして格納された前記第1署名済みコードには、有効期限が設定され、
前記第1制御部は、前記第1認証が要求された場合、前記有効期限が満了していない前記第1署名済みコードと前記第2署名済みコードとが対応するか否かを判定する、認証システム。 - 請求項1に記載の認証システムであって、
前記第1制御部は、前記第2ノードを認証した場合、前記第2ノードに前記第1情報を提供し、前記第1分散型台帳に、前記第2ノードに前記第1情報を提供したこと表す情報を記録する、認証システム。 - 請求項1に記載の認証システムであって、
前記第1情報は、前記第1分散型ネットワークからアクセス可能な第1データベースに格納され、
前記第2情報は、前記第2分散型ネットワークからアクセス可能な第2データベースに格納され、
前記第1制御部は、前記第2ノードを認証した場合、前記第2ノードに、前記第1データベースから取得した前記第1情報を提供し、
前記第2制御部は、前記第1ノードを認証した場合、前記第1ノードに、前記第2データベースから取得した前記第2情報を提供する、認証システム。 - 請求項1から7のいずれか一項に記載の認証システムであって、
前記第2制御部は、前記第1要求が実行された場合、前記ユーザ端末による前記ユーザの第1ローカル認証と、前記第1ローカル認証の後に前記第2制御部によって実行される前記ユーザ端末の第1公開鍵認証と、が完了した後に、前記第1ノードに前記第1認証を要求し、
前記第1制御部は、前記第2要求が実行された場合、前記ユーザ端末による前記ユーザの第2ローカル認証と、前記第2ローカル認証の後に前記第1制御部によって実行される前記ユーザ端末の第2公開鍵認証と、が完了した後に、前記第2ノードに前記第2認証を要求する、認証システム。 - ユーザによって使用されるユーザ端末であって、
ユーザ端末制御部を備え、
前記ユーザ端末制御部は、
第1分散型台帳を共有する複数のノードによって構成された第1分散型ネットワークに属し、前記ユーザに関する第1情報にアクセス可能な第1ノードに対して、第2要求を実行することが可能に構成され、
第2分散型台帳を共有する複数のノードによって構成された第2分散型ネットワークに属し、前記ユーザに関する第2情報にアクセス可能な第2ノードに対して、第1要求を実行することが可能に構成され、
前記第1分散型台帳の第1ウォレットには、前記第1情報のURIと、前記第2分散型台帳の第2ウォレットを指定する第1指定情報と、が格納され、前記第1指定情報は、非代替性を有するトークンである第1非代替性トークンとして格納され、
前記第2分散型台帳の前記第2ウォレットには、前記第2情報のURIと、前記第1ウォレットを指定する第2指定情報と、が格納され、前記第2指定情報は、非代替性を有するトークンである第2非代替性トークンとして格納され、
前記第1要求が実行された場合、前記第2ノードの第2制御部は、前記第2指定情報を用いて前記第1ウォレットを指定することで、前記第1ノードに、前記第1非代替性トークンに基づいて前記ユーザのために前記第2ノードを認証する第1認証を要求し、
前記第2要求が実行された場合、前記第1ノードの第1制御部は、前記第1指定情報を用いて前記第2ウォレットを指定することで、前記第2ノードに、前記第2非代替性トークンに基づいて前記ユーザのために前記第1ノードを認証する第2認証を要求する、ユーザ端末。 - 第1分散型ネットワークを構成する複数のノードによって共有された第1分散型台帳の第1ウォレットに、ユーザに関する第1情報のURIを格納する工程と、
前記第1ウォレットに、第2分散型ネットワークを構成する複数のノードによって共有された第2分散型台帳の第2ウォレットを指定する第1指定情報を、第1非代替性トークンとして格納する工程と、
前記第2ウォレットに、前記ユーザに関する第2情報のURIを格納する工程と、
前記第2ウォレットに、前記第1ウォレットを指定する第2指定情報を、第2非代替性トークンとして格納する工程と、
前記第2指定情報を用いて前記第1ウォレットを指定することで、前記第1分散型ネットワークに属し、前記第1情報にアクセス可能な第1ノードに対して、前記第1非代替性トークンに基づいて、前記ユーザのために、前記第2分散型ネットワークに属し前記第2情報にアクセス可能な第2ノードを認証することを要求する工程と、
前記第2ノードに対して、前記第1指定情報を用いて前記第2ウォレットを指定することで、前記第2非代替性トークンに基づいて前記ユーザのために前記第1ノードを認証することを要求する工程と、を備える、認証方法。 - ユーザによって使用されるユーザ端末を制御するコンピュータが実行するプログラムであって、
前記コンピュータに、
第1分散型台帳を共有する複数のノードによって構成された第1分散型ネットワークに属し、前記ユーザに関する第1情報にアクセス可能な第1ノードに対する第1要求を実行させる機能と、
第2分散型台帳を共有する複数のノードによって構成された第2分散型ネットワークに属し、前記ユーザに関する第2情報にアクセス可能な第2ノードに対する第2要求を実行させる機能と、を実現させ、
前記第1分散型台帳の第1ウォレットには、前記第1情報のURIと、前記第2分散型台帳の第2ウォレットを指定する第1指定情報と、が格納され、前記第1指定情報は、非代替性を有するトークンである第1非代替性トークンとして格納され、
前記第2分散型台帳の前記第2ウォレットには、前記第2情報のURIと、前記第1ウォレットを指定する第2指定情報と、が格納され、前記第2指定情報は、非代替性を有するトークンである第2非代替性トークンとして格納され、
前記第1要求が実行された場合、前記第2ノードの第2制御部は、前記第2指定情報を用いて前記第1ウォレットを指定することで、前記第1ノードに、前記第1非代替性トークンに基づいて前記ユーザのために前記第2ノードを認証する第1認証を要求し
前記第2要求が実行された場合、前記第1ノードの第1制御部は、前記第1指定情報を用いて前記第2ウォレットを指定することで、前記第2ノードに、前記第2非代替性トークンに基づいて前記ユーザのために前記第1ノードを認証する第2認証を要求する、プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/725,252 US20250062900A1 (en) | 2022-09-29 | 2023-08-18 | Authentication system, user terminal, authentication method, and program |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022-156298 | 2022-09-29 | ||
JP2022156298A JP7440590B1 (ja) | 2022-09-29 | 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 (3)
Country | Link |
---|---|
US (1) | US20250062900A1 (ja) |
JP (2) | JP7440590B1 (ja) |
WO (1) | WO2024070315A1 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020507143A (ja) | 2017-12-21 | 2020-03-05 | 株式会社BaaSid Lab Japan | ブロックチェーンを用いた一回性のアクセス権限付与システム |
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 | 充宏 前田 | 取引支援システム、取引支援方法及びプログラム |
-
2022
- 2022-09-29 JP JP2022156298A patent/JP7440590B1/ja active Active
-
2023
- 2023-08-18 US US18/725,252 patent/US20250062900A1/en active Pending
- 2023-08-18 WO PCT/JP2023/029831 patent/WO2024070315A1/ja active Application Filing
-
2024
- 2024-02-15 JP JP2024020739A patent/JP2024050917A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020507143A (ja) | 2017-12-21 | 2020-03-05 | 株式会社BaaSid Lab Japan | ブロックチェーンを用いた一回性のアクセス権限付与システム |
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 |
---|---|
US20250062900A1 (en) | 2025-02-20 |
JP7440590B1 (ja) | 2024-02-28 |
JP2024050917A (ja) | 2024-04-10 |
JP2024049829A (ja) | 2024-04-10 |
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 | |
CN110875821B (zh) | 密码学区块链互操作 | |
TW202217610A (zh) | 鑑認系統及方法 | |
US12206756B2 (en) | Electronic device within blockchain based PKI domain, electronic device within certification authority based PKI domain, and cryptographic communication system including these electronic devices | |
JP7462903B2 (ja) | 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム | |
TWI818209B (zh) | 基於分散式分類帳之憑證鑑別及憑證發布之方法及系統 | |
CN111767569A (zh) | 区块链的访问授权方法及节点 | |
TW202223793A (zh) | 驗證系統及方法 | |
TW202131659A (zh) | 用以儲存已認證資料於區塊鏈上之電腦實行方法及系統 | |
JP2023543470A (ja) | 物理複製困難関数に基づくチャレンジ応答プロトコル | |
CN113255014A (zh) | 一种基于区块链的数据处理方法以及相关设备 | |
TW202230397A (zh) | 實體不可仿製之功能 | |
TW202215814A (zh) | 實體不可仿製之功能 | |
TW202215815A (zh) | 實體不可仿製之功能 | |
US20240320376A1 (en) | Digital entity processing method, electronic device, storage medium | |
JP7440590B1 (ja) | 認証システム、ユーザ端末、認証方法、および、プログラム | |
CN113468600B (zh) | 一种数据授权方法、装置和设备 | |
KR102343461B1 (ko) | 스마트 컨트랙트의 외부 IoT 데이터 공급 방법 및 이를 위한 오라클 시스템 | |
US20230055866A1 (en) | Device and Method for Digital Utilization of Certificate Data, and Program Therefor | |
JP7624472B2 (ja) | 情報処理システム、および、情報処理方法 | |
Matsuo et al. | On universal composable security of time-stamping protocols | |
Khoury et al. | Distributed and Verifiable Digital Badges | |
CN119850203A (zh) | 基于区块链的资源兑换方法、装置、设备、介质及产品 | |
GB2612769A (en) | Authenticating a device |
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 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 18725252 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2023871557 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2023871557 Country of ref document: EP Effective date: 20250429 |