WO2022003864A1 - 登録者端末、検証者端末、管理システムおよびプログラム - Google Patents

登録者端末、検証者端末、管理システムおよびプログラム Download PDF

Info

Publication number
WO2022003864A1
WO2022003864A1 PCT/JP2020/025823 JP2020025823W WO2022003864A1 WO 2022003864 A1 WO2022003864 A1 WO 2022003864A1 JP 2020025823 W JP2020025823 W JP 2020025823W WO 2022003864 A1 WO2022003864 A1 WO 2022003864A1
Authority
WO
WIPO (PCT)
Prior art keywords
distributed ledger
ledger network
file
signature
network
Prior art date
Application number
PCT/JP2020/025823
Other languages
English (en)
French (fr)
Inventor
盛徳 大橋
啓太 鈴木
達郎 石田
昌義 近田
滋 藤村
篤 中平
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2022532921A priority Critical patent/JP7424490B2/ja
Priority to US18/011,689 priority patent/US20230254155A1/en
Priority to PCT/JP2020/025823 priority patent/WO2022003864A1/ja
Publication of WO2022003864A1 publication Critical patent/WO2022003864A1/ja

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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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

Definitions

  • the present invention relates to a registrant terminal, a verifier terminal, a management system and a program using distributed ledger technology.
  • blockchain which is a type of decentralized distributed ledger technology, is used. Since blockchain has high robustness against tampering, its use for various purposes such as smart contracts for transactions other than cryptocurrencies is being considered.
  • As a programmable blockchain that can handle smart contracts for example, there is Ethereum that can execute a general-purpose distributed application.
  • Distributed ledger technology that can realize various smart contracts has a data structure that organizes transactions into blocks and links the blocks with hashes, so it is not suitable for managing files with large data sizes.
  • Non-Patent Document 1 As a distributed file management method, there is a storage that manages files with a unique identifier (ID) created from a content hash or the like (see, for example, Non-Patent Document 1). There is also a method of registering a file in the storage and recording and managing the file ID in the distributed ledger (see, for example, Non-Patent Document 2).
  • ID unique identifier
  • each of the two systems has different functions and ID systems, so each system has it.
  • the present invention has been made by paying attention to the above circumstances, and an object thereof is to provide a registrant terminal, a verifier terminal, a management system and a program capable of realizing robust and flexible information management.
  • the registrant terminal can be connected to the first distributed ledger network and the second distributed ledger network.
  • the registrant terminal includes a registration unit, a first control unit, and a second control unit.
  • the registration unit registers the file in the external storage service.
  • the first control unit generates a registration transaction including a file identifier assigned to the file by the storage service and a verification key, and transmits the registration transaction to the first distributed ledger network.
  • the second control unit generates a token transaction relating to token generation, which includes a signature target message including the file identifier and a signature value obtained by digitally signing the signature target message with a signature key, and the token transaction. Is transmitted to the second distributed ledger network.
  • the verifier terminal can be connected to the first distributed ledger network and the second distributed ledger network.
  • the verifier terminal includes a first extraction unit, a second extraction unit, and a verification unit.
  • the first extraction unit refers to the second distributed ledger network, and uses the access information to the generated token to obtain the signature target message including the file identifier to be verified and the signature value of the signature target message.
  • the second extraction unit refers to the first distributed ledger network and extracts a verification key associated with the same file identifier as the file identifier.
  • the verification unit verifies the signature value using the verification key.
  • the management system is accessible to each of the first distributed ledger network, the second distributed ledger network, and the storage service, and includes a registrant terminal and a verifier terminal.
  • the registrant terminal includes a registration unit, a first control unit, and a second control unit.
  • the registration unit registers the file in the storage service.
  • the first control unit generates a registration transaction including a file identifier assigned to the file by the storage service and a verification key, and transmits the registration transaction to the first distributed ledger network.
  • the second control unit generates a token transaction relating to token generation, which includes a signature target message including the file identifier and a signature value obtained by digitally signing the signature target message with a signature key, and the token transaction.
  • the verifier terminal includes a first extraction unit, a second extraction unit, and a verification unit.
  • the first extraction unit refers to the second distributed ledger network, and uses the issued access information to the token to obtain a signature target message including a file identifier to be verified and a signature value of the signature target message.
  • the second extraction unit refers to the first distributed ledger network and extracts the same file identifier and verification key as the extracted file identifier.
  • the verification unit verifies the signature value using the verification key.
  • FIG. 1 is a conceptual diagram of a management system according to the present embodiment.
  • FIG. 2 is a block diagram showing a registrant terminal according to the present embodiment.
  • FIG. 3 is a block diagram showing a verifier terminal according to the present embodiment.
  • FIG. 4 is a sequence diagram showing an example of the registration process of the management system according to the present embodiment.
  • FIG. 5 is a sequence diagram showing an example of the association verification process of the management system according to the present embodiment.
  • FIG. 6 is a diagram showing an example of a signature target message according to the present embodiment.
  • the management system 10 includes a registrant terminal 1, a verifier terminal 2, a storage service 3, a first distributed ledger network 4, and a second distributed ledger network 5.
  • the registrant terminal 1 is a terminal that registers files in the storage service 3, and can be connected to the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5. Further, the registrant terminal 1 manages an account that can be connected to the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5, respectively, and a signature key associated with the account and a corresponding verification key. .. As the signature key, a common value may be used for the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5, or different values may be used for each.
  • the signature key may be stored in the registrant terminal 1, or may be managed in a storage location different from the registrant terminal 1, such as a cloud server, a dedicated device, or paper.
  • the verifier terminal 2 is a terminal that verifies the association between the file registered in the storage service 3 by the registrant terminal 1 and the token generated on the second distributed ledger network 5, and is a terminal that verifies the association between the storage service 3 and the first distributed ledger.
  • the ledger network 4 and the second distributed ledger network 5 can be accessed.
  • the verifier terminal 2 also manages the signature key associated with the account that can be connected to the first distributed ledger network 4 and the second distributed ledger network 5.
  • the storage service 3 is a service in which the registrant terminal 1 registers a file and manages the registered file. When the storage service 3 registers a file, the storage service 3 issues the file ID of the file.
  • the file ID is an identifier that uniquely identifies the file, and is also referred to as a file identifier.
  • the storage service 3 may be a centralized type in which a server (not shown) manages files, or terminals involved in the maintenance of the storage service 3, such as IPFS (InterPlanetary File System) and Swarm, are distributed and P2P (P2P). Peer to Peer) It may be a decentralized type that manages files on the network.
  • the first distributed ledger network 4 is a network using a decentralized distributed ledger technology that does not require a specific administrator.
  • the first distributed ledger network 4 assumes a blockchain network such as Namecoin that can register data in a key-value store format, but at least two elements can be related and managed by the distributed ledger, and transaction verification and execution can be performed. , Any distributed ledger technology that does not include the process acquired by a specific administrator in the process of registration to the ledger.
  • the second distributed ledger network 5 is a network using a logical centralized distributed ledger technology that requires a specific administrator.
  • the second distributed ledger network 5 assumes a blockchain network such as EOS and Ethereum that can realize a decentralized application (DApps) related to blockchain applications such as smart contracts, but is a program executed by a transaction. Any network using distributed ledger technology, in which registration and management are acquired by a specific administrator, may be used.
  • the first distributed ledger network 4 and the second distributed ledger network 5 are assumed to be different independent networks, but the data processing innately provided in the base does not require a specific administrator. 1st distributed ledger network 4 and 2nd distributed ledger network 5 in one distributed ledger network, if it is possible to distinguish between the layer of the above and the layer of data processing by a program registered by a specific administrator acquiredly. May be configured.
  • the registrant terminal 1 and the verifier terminal 2 may belong to the first distributed ledger network 4 and the second distributed ledger network 5, and may have a node function for maintaining their respective networks.
  • the node function is a function that performs transaction verification processing, approval processing, and update and retention of ledger information (block information, state database, etc.).
  • a terminal that substitutes for the node function may exist in the first distributed ledger network 4 and the second distributed ledger network 5.
  • another node 6 that maintains the first distributed ledger network 4 may exist, or another node 7 that maintains the second distributed ledger network 5 may exist.
  • the registrant terminal 1 and the verifier terminal 2 do not have to include the node function when another node 6 and another node 7 that substitute for the node function exist. In this embodiment, the case where the registrant terminal 1 and the verifier terminal 2 also execute the node function will be described.
  • the registrant terminal 1 includes a processing circuit 11, a storage unit 12, and a communication interface 13.
  • the processing circuit 11 includes an acquisition unit 111, a key generation unit 112, a first distributed ledger control unit 113, a second distributed ledger control unit 114, and a communication control unit 115.
  • the acquisition unit 111 acquires a file to be registered in the storage service 3.
  • the key generation unit 112 generates a key pair of a registrant's signature key and a verification key corresponding to the signature key, which is used for registration to the storage service 3, that is, for confirmation of association between a file and a token.
  • the key generation unit 112 generates a pair of a signature key for digitally signing a transaction and a corresponding verification key for issuing a transaction for each of the first distributed ledger network 4 and the second distributed ledger network 5. You may.
  • the first distributed ledger control unit 113 generates a registration transaction including the file ID assigned to the file by the storage service 3 and the verification key.
  • the first distributed ledger control unit 113 transmits the registration transaction to the first distributed ledger network 4. Further, the first distributed ledger control unit 113 executes a node function for maintaining the first distributed ledger network.
  • the second distributed ledger control unit 114 generates a token transaction regarding token data including a signature target message including a file ID and a signature value obtained by digitally signing the signature target message with the signature key of the registrant. .. Token data is data related to token issuance.
  • the second distributed ledger control unit 114 transmits the token transaction to the second distributed ledger network 5.
  • the second distributed ledger control unit 114 executes the node function in the same manner as the first distributed ledger control unit 113.
  • the communication control unit 115 controls data communication between the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5.
  • the communication control unit 115 performs a process of transmitting a file to the storage service 3 and receiving a file ID, it is also called a registration unit.
  • the storage unit 12 includes ledger data of the first distributed ledger network 4 and the second distributed ledger network 5, a key pair for issuing a transaction, a key pair for linking proof, a file, and an identifier of a registered transaction issued by itself (registered transaction). It also stores ID), access information to tokens, and so on.
  • the access information to the token is information for referring to the information stored in the token or the information stored in the token transaction used for token generation. Specifically, for example, the identifier of the token transaction (token). (Also referred to as a transaction ID), a contract address, access interface information, and an ID assigned or assigned to a token.
  • the communication interface 13 is an interface for data communication between the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5, respectively. Since the communication interface 13 may use a generally used communication interface, the description thereof is omitted here.
  • the verifier terminal 2 includes a processing circuit 21, a storage unit 22, and a communication interface 23.
  • the processing circuit 21 includes an acquisition unit 211, a first extraction unit 212, a second extraction unit 213, a verification unit 214, a first distributed ledger control unit 215, a second distributed ledger control unit 216, and a communication control unit. 217 and included.
  • the acquisition unit 211 verifies the information stored in the token or the information stored in the token transaction used for token generation by the verification process in the verification unit 214 described later, and the authenticity of the stored information can be confirmed.
  • the first extraction unit 212 refers to the second distributed ledger network 5 and extracts the signature target message including the file ID to be verified and the signature value by using the access information to the token.
  • the second extraction unit 213 refers to the first distributed ledger network 4 and extracts a verification key associated with the same file ID as the file ID.
  • the verification unit 214 verifies the signature value using the verification key.
  • the first distributed ledger control unit 215 and the second distributed ledger control unit 216 realize the same node functions as the first distributed ledger control unit 113 and the second distributed ledger control unit 114 of the registrant terminal 1, respectively.
  • the communication control unit 217 controls data communication between the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5.
  • the storage unit 22 stores ledger data of the first distributed ledger network 4 and the second distributed ledger network 5, a key pair for issuing a transaction, access information to a token, a registered transaction ID, and the like, if necessary.
  • the communication interface 23 performs almost the same processing as the communication interface 13 of the registrant terminal 1.
  • the processing circuit 11 of the registrant terminal 1 and the processing circuit 21 of the verifier terminal 2 are processors such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), or an FPGA (Field Programmable Gate Array) and an ASIC, respectively. It is composed of integrated circuits such as (Application Specific Integrated Circuit). Each part of the processing circuit 11 and the processing circuit 21 described above may be realized as one function of the processor or the integrated circuit by executing the processing program by the processor or the integrated circuit.
  • the storage unit 12 of the registrant terminal 1 and the storage unit 22 of the verifier terminal 2 are, for example, commonly used storage media such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), and a flash memory. It is composed.
  • FIG. 4 is a sequence showing a time series regarding data transmission / reception between the registrant terminal 1, the verifier terminal 2, the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5.
  • the verifier terminal 2 may also participate as a node to maintain the distributed ledger network.
  • step S401 the acquisition unit 111 of the registrant terminal 1 acquires the file from the storage unit 12 or the outside, and the communication control unit 115 transmits the file to the storage service 3.
  • step S402 the storage service 3 starts registering and managing the file received from the registrant terminal 1.
  • the storage service 3 issues a file ID for the file and transmits the file ID to the registrant terminal 1.
  • the file ID may be, for example, a character string created from the hash value of a file such as a fingerprint, or an ID including a phrase indicating a service provider in addition to the character string created from the hash value.
  • it may be an identifier such as a URI (Uniform Resource Identifier). That is, an identifier that can uniquely identify the file may be issued.
  • URI Uniform Resource Identifier
  • step S404 the key generation unit 112 of the registrant terminal 1 generates a signature key and a corresponding verification key for verifying the association between the file ID and the token.
  • the key generation unit 112 generates the signature key when the first file is registered in the storage service 3, and when the registrant subsequently registers the file, only the verification key is generated based on the signature key. You may try to do it. Further, when registering a plurality of files, the same key pair may be reused instead of generating a new key pair of the signature key and the corresponding verification key for each file.
  • step S405 the first distributed ledger control unit 113 of the registrant terminal 1 generates a registration transaction including a file ID and a verification key.
  • the first distributed ledger control unit 113 digitally signs the registration transaction with the signature key generated to use the first distributed ledger network 4, and digitally signs the registration transaction. Broadcast the registration transaction to the first distributed ledger network 4.
  • step S406 a plurality of terminals having a node function in the first distributed ledger network 4 verify a registration transaction by a consensus algorithm. If the registration transaction meets certain requirements, the registration transaction is included in the block. Here, assuming that the registration transaction satisfies a predetermined requirement, the registration transaction is confirmed by the first distributed ledger network 4.
  • the first distributed ledger control unit 113 of the registrant terminal 1 receives the registration result of the registration transaction from the first distributed ledger network 4.
  • the registration result is, for example, a registration transaction and an approval result (True or False or status code), and when the registration transaction is registered in a block, its block number.
  • step S408 a token transaction including a signature target message related to token issuance including a file ID and a signature value in which the signature target message is digitally signed with a signature key is generated.
  • the second distributed ledger control unit 114 digitally signs the token transaction with the signature key generated to use the second distributed ledger network 5, and digitally signs the token transaction. Broadcast the token transaction to the second distributed ledger network 5.
  • step S409 the second distributed ledger network 5 verifies the token transaction by the consensus algorithm. If the token transaction meets certain requirements, the token transaction is included in the block. Here, assuming that the token transaction satisfies a predetermined requirement, the token transaction is approved by the second distributed ledger network 5.
  • step S410 the registrant terminal 1 receives the registration result of the token transaction from the second distributed ledger network 5.
  • the registration result is, for example, a token transaction and an approval result (True or False or status code), and when a token transaction is registered in a block, its block number.
  • FIG. 5 is a sequence showing a time series of data exchange between the verifier terminal 2, the storage service 3, the first distributed ledger network 4, and the second distributed ledger network 5.
  • the registrant terminal 1 may also participate as a node to maintain the distributed ledger network.
  • the “request” and “return” in the sequence are illustrated as if they are accessing the first distributed ledger network 4 and the second distributed ledger network 5, but the first distributed ledger network. It can also be realized by the internal processing of the verifier terminal 2 without directly accessing the 4 and the second distributed ledger network 5. This is because when the verifier terminal 2 participates in the first distributed ledger network 4 and the second distributed ledger network 5 as a node, the verifier terminal 2 itself plays a part of the distributed ledger network. That is, by referring to the distributed ledger held by the verifier terminal 2, transactions and various data that match the verifier's request may be extracted.
  • step S501 the first extraction unit 212 of the verifier terminal 2 specifies the access information to the token to be verified, and uses the API or token transaction of the corresponding token for the second distributed ledger network 5 to file.
  • step S502 the signature target message including the file ID and the signature value are returned from the second distributed ledger network 5 in response to the request from the verifier terminal 2.
  • the processes of step 501 and step S502 may be executed as a process in which the first extraction unit 212 of the verifier terminal 2 refers to the second distributed ledger network 5 to extract the file ID and the signature value.
  • step S503 the second extraction unit 213 of the verifier terminal 2 requests the first distributed ledger network 4 for the verification key associated with the same file ID as the extracted file ID by the registration transaction.
  • step S504 the first distributed ledger network 4 returns the verification key corresponding to the file ID in response to the request from the verifier terminal 2.
  • the processes of steps 503 and S504 may be executed as a process in which the second extraction unit 213 of the verifier terminal 2 extracts the file ID and the signature value with reference to the first distributed ledger network 4. Further, for example, when the first distributed ledger network 4 is realized by Bitcoin Core, a registered transaction matching the registered transaction ID may be searched from the ledger and a verification key associated with the file ID may be obtained.
  • step S505 the verification unit 214 of the verifier terminal 2 verifies the signature value with the verification key.
  • the verifier terminal 2 may acquire the file based on the token. Specifically, in step S506, the acquisition unit 211 of the verifier terminal 2 specifies a file ID and requests a file from the storage service 3. In step S507, the storage service 3 may search the database for the file corresponding to the file ID and send it to the verifier terminal 2. The verifier terminal 2 may receive the shared registration transaction ID directly or indirectly from the registrant terminal 1 in the first distributed ledger network 4, and store the shared registration transaction ID in the storage unit 22. ..
  • the second extraction unit 213 can efficiently extract the verification key by referring to the shared registration transaction ID stored in the storage unit 22 in step S503. For example, when the distributed ledger network of Bitcoin is utilized as the first distributed ledger network 4, if the registered transaction ID is shared, it is useful when extracting the verification key.
  • the signature target message 60 shown in FIG. 6 is, for example, a message described in a data field of a token transaction.
  • the signature target message 60 indicates a “fileId” indicating a file ID, a “storageservice” indicating the type of the storage service 3, a “date” indicating a date, and the original owner (for example, the author) of the file. Includes “original owner” items.
  • storage service an access destination such as a server domain or a protocol may be indicated. Not limited to this, other items may be included.
  • a random number item may be added to make the message to be signed unique. By adding a random number item, the signature target message can be easily identified even if there are a plurality of signature target messages having the same content.
  • the second distributed ledger control unit 114 of the registrant terminal 1 digitally signs the signature target message 60 with the signature key, and includes the signature value in the token transaction.
  • the verification unit 214 of the verifier terminal 2 can verify the authenticity that the file corresponding to the file ID is registered by the registrant terminal by verifying the signature value with the verification key associated with the file ID.
  • the file ID and the verification key are managed by a decentralized distributed ledger network that does not require a specific administrator.
  • the message to be signed regarding the issuance of the token including the file ID and the signature value by the signing key are managed by a logical centralized distributed ledger network that realizes DApps and requires a specific administrator.
  • the instructions given in the processing procedure shown in the above-described embodiment can be executed by a computer based on a program that is software.
  • the present invention is not limited to the above embodiment as it is, and at the implementation stage, the components can be modified and embodied within a range that does not deviate from the gist thereof.
  • various inventions can be formed by an appropriate combination of the plurality of components disclosed in the above-described embodiment. For example, some components may be removed from all the components shown in the embodiments. In addition, components from different embodiments may be combined as appropriate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本実施形態に係る登録者端末は、第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能である。登録者端末は、登録部と、第１制御部と、第２制御部とを含む。登録部は、外部のストレージサービスにファイルを登録する。第１制御部は、前記ストレージサービスにより前記ファイルに付与されたファイル識別子と、検証鍵とを含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記ファイル識別子を含む署名対象メッセージと、前記署名対象メッセージを署名鍵でデジタル署名することで得られる署名値とを含む、トークンの生成に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。

Description

登録者端末、検証者端末、管理システムおよびプログラム
　この発明は、分散台帳技術を利用した登録者端末、検証者端末、管理システムおよびプログラムに関する。
　ビットコイン（登録商標）に代表される暗号通貨の取引においては、非中央集権型の分散台帳技術の一種であるブロックチェーンが用いられている。ブロックチェーンは、改ざんに対して高い堅牢性を有するため、暗号通貨以外の取引を行うスマートコントラクトなど様々な用途への利用が検討されている。スマートコントラクトを扱うことができるプログラマブルなブロックチェーンとして、例えば、汎用的な分散アプリケーションが実行できるイーサリアム（Ｅｔｈｅｒｅｕｍ）がある。
　様々なスマートコントラクトを実現可能な分散台帳技術は、トランザクションをブロックにまとめ、ブロック間をハッシュで連関させるデータ構造を持つため、データサイズが大きなファイルの管理には不向きである。
　分散型のファイル管理の方法として、コンテンツハッシュなどから作られるユニークな識別子（ＩＤ）でファイルを管理するストレージがある（例えば、非特許文献１参照）。また、当該ストレージにファイルを登録し、ファイルのＩＤを分散台帳に記録して管理する方法もある（例えば、非特許文献２参照）。
Juan Banet、"IPFS - Content Addressed, Versioned, P2P File System (DRAFT 3)"、［online］、［令和２年２月２７日検索］、インターネット〈URL：https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf〉 Mathis Steichen, 他、"Blockchain-Based, Decentralized Access Control for IPFS"、［online］、［令和２年２月２７日検索］、インターネット〈URL：https://www.researchgate.net/publication/327034734_Blockchain-Based_Decentralized_Access_Control_for_IPFS〉
　分散台帳と分散ファイルストレージとのように、別々のシステムをユーザ側で連携して併用する場合、２つのシステムそれぞれがユーザに対して提供する機能やＩＤの体系が異なるため、それぞれの系で持つ情報が常に整合が取れていることを保証できない。
　例えば、分散台帳のトークンとファイルのＩＤとを関連づけて管理することを想定すると、あるトークンコントラクトにファイルＩＤを登録、別のトークンコントラクトに同じファイルＩＤを登録した場合、どちらが正しいかを判断できない。
　先に生成され、分散台帳で承認されたコントラクトを正規なものとみなすという判定を行なった場合、無数にあるコントラクトを検索し、その中に記述されるトークンを全て抽出する必要性があり現実的ではない。ファイルの紐付けの管理のために新たなコントラクトを立てると、そのコントラクトに依存する関係になってしまう。結果として、特定のアプリケーションに論理的に依存する構造は、当該特定のアプリケーションが単一障害点となり得る。
　この発明は上記事情に着目してなされたもので、その目的とするところは、ロバストかつ柔軟な情報管理を実現できる登録者端末、検証者端末、管理システムおよびプログラムを提供することにある。
　上記目的を達成するために、この発明の一つの観点に係る登録者端末は、第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能である。登録者端末は、登録部と、第１制御部と、第２制御部とを含む。登録部は、外部のストレージサービスにファイルを登録する。第１制御部は、前記ストレージサービスにより前記ファイルに付与されたファイル識別子と、検証鍵とを含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記ファイル識別子を含む署名対象メッセージと、前記署名対象メッセージを署名鍵でデジタル署名することで得られる署名値とを含む、トークンの生成に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。
　また、この発明の一つの観点に係る検証者端末は、第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能である。検証者端末は、第１抽出部と、第２抽出部と、検証部とを含む。第１抽出部は、前記第２分散台帳ネットワークを参照して、生成されたトークンへのアクセス情報を用いて、検証対象となるファイル識別子を含む署名対象メッセージと前記署名対象メッセージの署名値とを抽出する。第２抽出部は、前記第１分散台帳ネットワークを参照して、前記ファイル識別子と同一のファイル識別子に紐付く検証鍵を抽出する。検証部は、前記検証鍵を用いて前記署名値を検証する。
　また、この発明の一つの観点に係る管理システムは、第１分散台帳ネットワークと、第２分散台帳ネットワークと、ストレージサービスとのそれぞれにアクセス可能であり、登録者端末および検証者端末を含む。登録者端末は、登録部と、第１制御部と、第２制御部とを含む。登録部は、前記ストレージサービスにファイルを登録する。第１制御部は、前記ストレージサービスにより前記ファイルに付与されたファイル識別子と、検証鍵とを含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記ファイル識別子を含む署名対象メッセージと、前記署名対象メッセージを署名鍵でデジタル署名することで得られる署名値とを含む、トークンの生成に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。前記検証者端末は、第１抽出部と、第２抽出部と、検証部とを含む。第１抽出部は、前記第２分散台帳ネットワークを参照して、発行された前記トークンへのアクセス情報を用いて、検証対象となるファイル識別子を含む署名対象メッセージと前記署名対象メッセージの署名値とを抽出する。第２抽出部は、前記第１分散台帳ネットワークを参照して、抽出した前記ファイル識別子と同一のファイル識別子および検証鍵を抽出する。検証部は、前記検証鍵を用いて前記署名値を検証する。
　すなわちこの発明によれば、ロバストかつ柔軟な情報管理を実現できる。
図１は、本実施形態に係る管理システムの概念図である。 図２は、本実施形態に係る登録者端末を示すブロック図である。 図３は、本実施形態に係る検証者端末を示すブロック図である。 図４は、本実施形態に係る管理システムの登録処理の一例を示すシーケンス図である。 図５は、本実施形態に係る管理システムの紐付け検証処理の一例を示すシーケンス図である。 図６は、本実施形態に係る署名対象メッセージの一例を示す図である。
　以下、図面を参照しながら本開示の一実施形態に係る登録者端末、検証者端末、管理システムおよびプログラムについて詳細に説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
　本実施形態に係る管理システムについて図１の概念図を参照して説明する。
　本実施形態に係る管理システム１０は、登録者端末１と、検証者端末２と、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とを含む。
　登録者端末１は、ファイルをストレージサービス３に登録する端末であり、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とに接続可能である。また、登録者端末１は、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とにそれぞれ接続可能なアカウントおよびアカウントに紐付く署名鍵と対応する検証鍵とを管理する。なお、署名鍵は、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とで共通の値を用いてもよいし、それぞれ異なる値を用いてもよい。署名鍵は、登録者端末１に保存されてもよいし、クラウドサーバ、専用デバイス、紙などの登録者端末１とは異なる保存場所で管理されてもよい。
　検証者端末２は、登録者端末１がストレージサービス３に登録したファイルと、第２分散台帳ネットワーク５上に生成したトークンとの紐付けを検証する端末であり、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とにアクセス可能である。検証者端末２も登録者端末１と同様に、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に接続可能なアカウントに紐付く署名鍵を管理する。
　ストレージサービス３は、登録者端末１がファイルを登録し、登録されたファイルを管理するサービスである。ストレージサービス３は、ファイルを登録した場合、当該ファイルのファイルＩＤを発行する。ファイルＩＤは、当該ファイルを一意に識別する識別子であり、ファイル識別子ともいう。ストレージサービス３は、サーバ（図示せず）がファイルを管理する中央集権型でもよいし、ＩＰＦＳ（InterPlanetary File System）やＳｗａｒｍなどの、ストレージサービス３の維持に関与する各端末が分散してＰ２Ｐ（Peer to Peer）ネットワークでファイルを管理する非中央集権型でもよい。
　第１分散台帳ネットワーク４は、特定の管理者を必要としない非中央集権型の分散台帳技術を用いたネットワークである。第１分散台帳ネットワーク４は、ここではｋｅｙ－ｖａｌｕｅストア形式でデータを登録可能なＮａｍｅｃｏｉｎなどのブロックチェーンネットワークを想定するが、少なくとも２つの要素を関連づけて分散台帳で管理でき、トランザクションの検証、実行、台帳への登録の過程で、特定の管理者により後天的に登録された処理を含まない分散台帳技術であればよい。
　第２分散台帳ネットワーク５は、特定の管理者が必要となる、論理的な中央集権型の分散台帳技術を用いたネットワークである。第２分散台帳ネットワーク５は、ここではスマートコントラクトなどのブロックチェーンの応用に関する分散型アプリケーション（ＤＡｐｐｓ）を実現可能な、ＥＯＳ、イーサリアムなどのブロックチェーンネットワークを想定するが、トランザクションにより実行されるプログラムの登録や管理が特定の管理者により後天的に行われる分散台帳技術を用いたネットワークであればよい。
　なお、本実施形態では、第１分散台帳ネットワーク４と第２分散台帳ネットワーク５とは、異なる独立のネットワークを想定するが、基盤に先天的に備わった、特定の管理者を必要としないデータ処理の層と、後天的に特定の管理者により登録されたプログラムによるデータ処理の層とを区別して利用可能であれば、１つの分散台帳ネットワークで第１分散台帳ネットワーク４および第２分散台帳ネットワーク５を構成してもよい。
　なお、登録者端末１および検証者端末２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に属し、それぞれのネットワークを維持するためのノード機能を有してもよい。ノード機能は、トランザクションの検証処理や承認処理、台帳情報（ブロック情報、ステートデータベースなど）の更新および保持を行なう機能である。
　なお、登録者端末１および検証者端末２以外にも、ノード機能を代替する端末（別ノードという）が第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に存在してもよい。図１の例では、第１分散台帳ネットワーク４を維持する別ノード６が存在してもよいし、第２分散台帳ネットワーク５を維持する別ノード７が存在してもよい。登録者端末１および検証者端末２は、ノード機能を代替する別ノード６および別ノード７が存在する場合は、ノード機能を含まなくともよい。なお、本実施形態では、登録者端末１および検証者端末２もノード機能を実行する場合について説明する。
　次に、本実施形態に係る登録者端末１について図２のブロック図を参照して説明する。
　登録者端末１は、処理回路１１と、格納部１２と、通信インタフェース１３とを含む。処理回路１１は、取得部１１１と、鍵生成部１１２と、第１分散台帳制御部１１３と、第２分散台帳制御部１１４と、通信制御部１１５とを含む。
　取得部１１１は、ストレージサービス３に登録するためのファイルを取得する。
　鍵生成部１１２は、ストレージサービス３への登録用、つまりファイルとトークンとの紐付け確認用となる、登録者の署名鍵および署名鍵に対応する検証鍵の鍵ペアを生成する。なお、鍵生成部１１２は、トランザクション発行用に、トランザクションにデジタル署名をするための署名鍵と対応する検証鍵とのペアを、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５それぞれについて生成してもよい。
　第１分散台帳制御部１１３は、ストレージサービス３によりファイルに付与されたファイルＩＤと、検証鍵とを含む、登録トランザクションを生成する。第１分散台帳制御部１１３は、登録トランザクションを第１分散台帳ネットワーク４に送信する。また、第１分散台帳制御部１１３は、第１分散台帳ネットワークを維持するためのノード機能を実行する。
　第２分散台帳制御部１１４は、ファイルＩＤを含む署名対象メッセージと、当該署名対象メッセージに登録者の署名鍵でデジタル署名することで得られる署名値とを含む、トークンデータに関するトークントランザクションを生成する。トークンデータは、トークン発行に関するデータである。第２分散台帳制御部１１４は、トークントランザクションを第２分散台帳ネットワーク５に送信する。第２分散台帳制御部１１４は、第１分散台帳制御部１１３と同様にノード機能を実行する。
　通信制御部１１５は、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５との間のデータ通信を制御する。特に、通信制御部１１５が、ストレージサービス３にファイルを送信し、ファイルＩＤを受信する処理を行う場合は、登録部とも呼ぶ。
　格納部１２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の台帳データ、トランザクション発行用の鍵ペア、紐付け証明用の鍵ペア、ファイル、自身が発行した登録トランザクションの識別子（登録トランザクションＩＤともいう）、トークンへのアクセス情報などを格納する。トークンへのアクセス情報は、トークンに格納された情報、またはトークン生成に使用されたトークントランザクションに格納された情報を参照するための情報であり、具体的には、例えば、トークントランザクションの識別子（トークントランザクションＩＤともいう）、コントラクトアドレス、アクセス用インターフェース情報、トークンに振るまたは振られるＩＤが挙げられる。
　通信インタフェース１３は、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５との間で、それぞれデータ通信するためのインタフェースである。通信インタフェース１３は、一般的に用いられている通信インタフェースを用いればよいため、ここでの説明は省略する。
　次に、本実施形態に係る検証者端末２について図３のブロック図を参照して説明する。
　検証者端末２は、処理回路２１と、格納部２２と、通信インタフェース２３とを含む。処理回路２１は、取得部２１１と、第１抽出部２１２と、第２抽出部２１３と、検証部２１４と、第１分散台帳制御部２１５と、第２分散台帳制御部２１６と、通信制御部２１７とを含む。
　取得部２１１は、後述の検証部２１４における検証処理により、トークンに格納された情報、またはトークン生成に使用されたトークントランザクションに格納された情報を検証し、格納情報の真正性が確認できた場合、ストレージサービス３から、ファイルＩＤに対応するファイルを取得する。
　第１抽出部２１２は、第２分散台帳ネットワーク５を参照して、トークンへのアクセス情報を用いて、検証対象となるファイルＩＤを含む署名対象メッセージと署名値とを抽出する。
　第２抽出部２１３は、第１分散台帳ネットワーク４を参照して、ファイルＩＤと同一のファイルＩＤに紐付く検証鍵を抽出する。
　検証部２１４は、検証鍵を用いて署名値を検証する。
　第１分散台帳制御部２１５と第２分散台帳制御部２１６とはそれぞれ、登録者端末１の第１分散台帳制御部１１３と第２分散台帳制御部１１４と同様のノード機能を実現する。
　通信制御部２１７は、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５との間のデータ通信を制御する。
　格納部２２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の台帳データ、トランザクション発行用の鍵ペア、トークンへのアクセス情報、または、必要に応じて登録トランザクションＩＤなどを格納する。
　通信インタフェース２３は、登録者端末１の通信インタフェース１３とほぼ同様の処理を行う。
　なお、登録者端末１の処理回路１１および検証者端末２の処理回路２１はそれぞれ、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）などのプロセッサ、または、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などの集積回路で構成される。上述した処理回路１１および処理回路２１の各部は、プロセッサまたは集積回路が処理プログラムを実行することで、プロセッサまたは集積回路の一機能として実現されてもよい。
　また、登録者端末１の格納部１２および検証者端末２の格納部２２はそれぞれ、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの一般的に用いられる記憶媒体で構成される。
　次に、本実施形態に係る管理システム１０のファイル登録処理について図４のシーケンス図を参照して説明する。
　図４は、登録者端末１と、検証者端末２と、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５との間のデータ送受信に関する時系列を示すシーケンスである。なお、図示しないが、検証者端末２も分散台帳ネットワーク維持のためにノードとして参加してもよい。
　ステップＳ４０１では、登録者端末１の取得部１１１が、格納部１２または外部からファイルを取得し、通信制御部１１５が、ファイルをストレージサービス３に送信する。
　ステップＳ４０２では、ストレージサービス３が、登録者端末１から受信したファイルを登録および管理を開始する。
　ステップＳ４０３では、ストレージサービス３が、ファイルに対するファイルＩＤを発行し、当該ファイルＩＤを登録者端末１に送信する。ファイルＩＤは、例えば、フィンガープリントのようなファイルのハッシュ値から作られる文字列でもよいし、ハッシュ値から作られる文字列に加えて、サービス提供者を示すフレーズを含めたＩＤでもよい。または、ＵＲＩ（Uniform Resource Identifier）のような識別子であってもよい。すなわち、ファイルを一意に識別可能な識別子が発行されればよい。
　登録者端末１の通信制御部１１５が、ファイルＩＤを受信することで、ストレージサービス３へのファイルの登録処理が完了する。
　ステップＳ４０４では、登録者端末１の鍵生成部１１２が、ファイルＩＤとトークンとの紐付けを検証するための署名鍵および対応する検証鍵を生成する。なお、鍵生成部１１２は、署名鍵は、最初のファイルをストレージサービス３に登録する際に生成し、登録者がその後にファイルを登録する際には、署名鍵に基づいて検証鍵のみを生成するようにしてもよい。また、複数のファイルを登録する場合に、ファイルごとに、署名鍵と対応する検証鍵との鍵ペアを新しく生成するのではなく、同じ鍵対を使い回してもよい。
　ステップＳ４０５では、登録者端末１の第１分散台帳制御部１１３が、ファイルＩＤと検証鍵とを含む登録トランザクションを生成する。第１分散台帳制御部１１３は、登録トランザクションを有効なトランザクションとするため、登録トランザクションに対して第１分散台帳ネットワーク４を利用するために生成された署名鍵でデジタル署名を行ない、デジタル署名された登録トランザクションを第１分散台帳ネットワーク４にブロードキャストする。
　ステップＳ４０６では、第１分散台帳ネットワーク４においてノード機能を有する複数の端末が、コンセンサスアルゴリズムにより、登録トランザクションを検証する。当該登録トランザクションが所定の要件を満たしていれば、登録トランザクションがブロックに取り込まれる。ここでは登録トランザクションが所定の要件を満たすとして、第１分散台帳ネットワーク４により登録トランザクションが承認（confirm）される。
　ステップＳ４０７では、登録者端末１の第１分散台帳制御部１１３が、第１分散台帳ネットワーク４から登録トランザクションの登録結果を受信する。登録結果は、例えば、登録トランザクションと承認結果（True or Falseまたはステータスコード）、登録トランザクションがブロックに登録された場合、そのブロック番号である。
　ステップＳ４０８では、ファイルＩＤを含むトークン発行に関する署名対象メッセージと、署名対象メッセージを署名鍵でデジタル署名した署名値とを含むトークントランザクションを生成する。第２分散台帳制御部１１４は、トークントランザクションを有効なトランザクションとするため、トークントランザクションに対して第２分散台帳ネットワーク５を利用するために生成された署名鍵によりデジタル署名を行ない、デジタル署名されたトークントランザクションを第２分散台帳ネットワーク５にブロードキャストする。
　ステップＳ４０９では、第２分散台帳ネットワーク５が、コンセンサスアルゴリズムにより、トークントランザクションを検証する。当該トークントランザクションが所定の要件を満たしていれば、トークントランザクションがブロックに取り込まれる。ここではトークントランザクションが所定の要件を満たすとして、第２分散台帳ネットワーク５によりトークントランザクションが承認される。
　ステップＳ４１０では、登録者端末１が、第２分散台帳ネットワーク５からトークントランザクションの登録結果を受信する。登録結果は、例えばトークントランザクションと承認結果（True or Falseまたはステータスコード）、トークントランザクションがブロックに登録された場合、そのブロック番号である。
　次に、本実施形態に係る管理システム１０のファイルとトークンとの紐付け検証処理について図５のシーケンス図を参照して説明する。
　図５は、検証者端末２と、ストレージサービス３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５とに関する、データのやりとりの時系列を示すシーケンスである。なお、図示しないが、登録者端末１も分散台帳ネットワーク維持のためにノードとして参加してもよい。
　また、図５では、説明の便宜上、シーケンスにおける「要求」および「返却」は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５にアクセスしているように図示するが、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に直接アクセスせずに、検証者端末２の内部処理で実現することもできる。これは、検証者端末２がノードとして第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に参加している場合は、検証者端末２自身が分散台帳ネットワークの一部を担うからである。つまり、検証者端末２が保持する分散台帳を参照することで、検証者の要求に合致するトランザクションおよび各種データなどを抽出すればよい。
　ステップＳ５０１では、検証者端末２の第１抽出部２１２が、検証したいトークンへのアクセス情報を指定して、第２分散台帳ネットワーク５に対し、対応するトークンのＡＰＩまたはトークントランザクションを用いて、ファイルＩＤを含む署名対象メッセージと署名値とを要求する。
　ステップＳ５０２では、第２分散台帳ネットワーク５から、検証者端末２からの要求に応じて、ファイルＩＤを含む署名対象メッセージと署名値とが返却される。なお、ステップ５０１およびステップＳ５０２の処理は、検証者端末２の第１抽出部２１２が、第２分散台帳ネットワーク５を参照してファイルＩＤおよび署名値を抽出する処理として実行されてもよい。
　ステップＳ５０３では、検証者端末２の第２抽出部２１３が、第１分散台帳ネットワーク４に対し、抽出したファイルＩＤと同一のファイルＩＤに登録トランザクションにより紐付けられた検証鍵を要求する。
　ステップＳ５０４では、第１分散台帳ネットワーク４が、検証者端末２からの要求に応じて、ファイルＩＤに対応する検証鍵を返却する。なお、ステップ５０３およびステップＳ５０４の処理は、検証者端末２の第２抽出部２１３が、第１分散台帳ネットワーク４を参照してファイルＩＤおよび署名値を抽出する処理として実行されてもよい。また、例えばＢｉｔｃｏｉｎ　Ｃｏｒｅで第１分散台帳ネットワーク４を実現する場合、台帳から登録トランザクションＩＤと一致する登録トランザクションを検索して、ファイルＩＤに紐付く検証鍵を取得すればよい。
　ステップＳ５０５では、検証者端末２の検証部２１４が、検証鍵で署名値を検証する。
　なお、署名値の検証に成功した場合、例えば検証者端末２が、トークンに基づきファイルを取得してもよい。
　具体的には、ステップＳ５０６では、検証者端末２の取得部２１１が、ファイルＩＤを指定してストレージサービス３に対してファイルを要求する。
　ステップＳ５０７では、ストレージサービス３が、ファイルＩＤに対応するファイルをデータベースから検索し、検証者端末２に送信すればよい。
　なお、検証者端末２は、第１分散台帳ネットワーク４において、登録者端末１から直接または間接的に登録トランザクションＩＤの共有を受け、共有された登録トランザクションＩＤを格納部２２に保存してもよい。第２抽出部２１３は、ステップＳ５０３において格納部２２に保存される、共有された登録トランザクションＩＤを参照することで効率的に検証鍵の抽出が実行できる。例えば、ビットコインの分散台帳ネットワークを第１分散台帳ネットワーク４として活用する場合、登録トランザクションＩＤが共有されていれば、検証鍵を抽出する際に有益である。
　次に、署名鍵によりデジタル署名される署名対象メッセージの一例について図６を参照して説明する。
　図６に示す署名対象メッセージ６０は、例えばトークントランザクションのデータフィールドに記載されるメッセージである。署名対象メッセージ６０は、ここでは、ファイルＩＤを示す「fileId」、ストレージサービス３の種類を示す「storageservice」、日付を示す「date」、およびファイルの元の所有者（例えば、著作者）を示す「originalowner」の項目を含む。「storageservice」として、サーバ・ドメインやプロトコルなどアクセス先を示してもよい。なお、これに限らず、他の項目を含んでもよい。例えば、「date」の他に、署名対象メッセージをユニークとするため、乱数の項目を追加してもよい。乱数の項目を追加することで、内容としては同じ署名対象メッセージが複数存在しても、容易に署名対象メッセージを識別できる。
　登録者端末１の第２分散台帳制御部１１４は、署名対象メッセージ６０に対して署名鍵でデジタル署名し、署名値をトークントランザクションに含める。検証者端末２の検証部２１４は、ファイルＩＤと紐付く検証鍵により署名値を検証することで、ファイルＩＤに対応するファイルが登録者端末により登録されたことの真正性を検証できる。
　以上に示した実施形態によれば、データサイズの大きいファイルをストレージサービスで管理する場合に、ファイルＩＤと検証鍵とを、特定の管理者を必要としない非中央集権型の分散台帳ネットワークで管理し、ファイルＩＤを含むトークン発行に関する署名対象メッセージと署名鍵による署名値とを、ＤＡｐｐｓが実現される、特定の管理者が必要となる、論理的な中央集権型の分散台帳ネットワークで管理する。
　当該ファイルを利用する様々なポリシーを有するＤＡｐｐｓが増加したり、ＤＡｐｐｓのポリシーに変更がある場合でも、検証のための基本的な仕組みを非中央集権型の分散台帳ネットワークで管理することで、１つのＤＡｐｐｓによるサービス（コントラクト）にプログラムバグや管理者による意図的なまたは偶発的な破壊などの障害が発生しても、単一障害点とならずに、他のサービスの真正性の検証に影響を及ぼさない。結果として、ロバストかつ柔軟な情報管理を実現できる。
　上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいてコンピュータで実行されることが可能である。
　要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
１０…管理システム
１…登録者端末
２…検証者端末
３…ストレージサービス
４…第１分散台帳ネットワーク
５…第２分散台帳ネットワーク
６，７…別ノード
１１，２１…処理回路
１２，２２…格納部
１３，２３…通信インタフェース
６０…署名対象メッセージ
１１１，２１１…取得部
１１２…鍵生成部
１１３，２１５…第１分散台帳制御部
１１４，２１６…第２分散台帳制御部
１１５，２１７…通信制御部
１１５…分散台帳制御部
２１２…第１抽出部
２１３…第２抽出部
２１４…検証部

Claims (6)

  1. 　第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能な登録者端末であって、
    　外部のストレージサービスにファイルを登録する登録部と、
    　前記ストレージサービスにより前記ファイルに付与されたファイル識別子と、検証鍵とを含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する第１制御部と、
    　前記ファイル識別子を含む署名対象メッセージと、前記署名対象メッセージを署名鍵でデジタル署名することで得られる署名値とを含む、トークンの生成に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する第２制御部と、
    　を具備する登録者端末。
  2. 　第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能な検証者端末であって、
    　前記第２分散台帳ネットワークを参照して、発行されたトークンへのアクセス情報を用いて、検証対象となるファイル識別子を含む署名対象メッセージと前記署名対象メッセージの署名値とを抽出する第１抽出部と、
    　前記第１分散台帳ネットワークを参照して、前記ファイル識別子と同一のファイル識別子に紐付く検証鍵を抽出する第２抽出部と、
    　前記検証鍵を用いて前記署名値を検証する検証部と、
    　を具備する検証者端末。
  3. 　前記第１分散台帳ネットワークは、特定の管理者を必要としない非中央集権型のブロックチェーンネットワークであり、前記第２分散台帳ネットワークは、特定の管理者が必要となる、論理的な中央集権型のブロックチェーンネットワークである、請求項１に記載の登録者端末または請求項２に記載の検証者端末。
  4. 　第１分散台帳ネットワークと、第２分散台帳ネットワークと、ストレージサービスとのそれぞれにアクセス可能な、登録者端末および検証者端末を含む管理システムであって、
    　前記登録者端末は、
    　　前記ストレージサービスにファイルを登録する登録部と、
    　　前記ストレージサービスにより前記ファイルに付与されたファイル識別子と、検証鍵とを含む、登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する第１制御部と、
    　　前記ファイル識別子を含む署名対象メッセージと、前記署名対象メッセージを署名鍵でデジタル署名することで得られる署名値とを含む、トークンの生成に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する第２制御部と、を具備し、
    　前記検証者端末は、
    　　前記第２分散台帳ネットワークを参照して、前記トークンへのアクセス情報を用いて、検証対象となるファイル識別子を含む署名対象メッセージと前記署名対象メッセージの署名値とを抽出する第１抽出部と、
    　　前記第１分散台帳ネットワークを参照して、前記ファイル識別子と同一のファイル識別子に紐付く検証鍵を抽出する第２抽出部と、
    　　前記検証鍵を用いて前記署名値を検証する検証部と、
    　を具備する管理システム。
  5. 　コンピュータを、請求項１に記載の登録者端末の各部として実行させるためのプログラム。
  6. 　コンピュータを、請求項２に記載の検証者端末の各部として実行させるためのプログラム。
PCT/JP2020/025823 2020-07-01 2020-07-01 登録者端末、検証者端末、管理システムおよびプログラム WO2022003864A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022532921A JP7424490B2 (ja) 2020-07-01 2020-07-01 登録者端末、検証者端末、管理システムおよびプログラム
US18/011,689 US20230254155A1 (en) 2020-07-01 2020-07-01 Registration terminal, verification terminal, management system and program
PCT/JP2020/025823 WO2022003864A1 (ja) 2020-07-01 2020-07-01 登録者端末、検証者端末、管理システムおよびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/025823 WO2022003864A1 (ja) 2020-07-01 2020-07-01 登録者端末、検証者端末、管理システムおよびプログラム

Publications (1)

Publication Number Publication Date
WO2022003864A1 true WO2022003864A1 (ja) 2022-01-06

Family

ID=79314954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/025823 WO2022003864A1 (ja) 2020-07-01 2020-07-01 登録者端末、検証者端末、管理システムおよびプログラム

Country Status (3)

Country Link
US (1) US20230254155A1 (ja)
JP (1) JP7424490B2 (ja)
WO (1) WO2022003864A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017204704A (ja) * 2016-05-10 2017-11-16 日本電信電話株式会社 正当性保証方法、正当性保証システム及び正当性保証プログラム
JP2019185658A (ja) * 2018-04-17 2019-10-24 株式会社電通 Ｉｄ利用システム及びｉｄ利用方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017204704A (ja) * 2016-05-10 2017-11-16 日本電信電話株式会社 正当性保証方法、正当性保証システム及び正当性保証プログラム
JP2019185658A (ja) * 2018-04-17 2019-10-24 株式会社電通 Ｉｄ利用システム及びｉｄ利用方法

Also Published As

Publication number Publication date
US20230254155A1 (en) 2023-08-10
JP7424490B2 (ja) 2024-01-30
JPWO2022003864A1 (ja) 2022-01-06

Similar Documents

Publication Publication Date Title
US11349674B2 (en) Digital certificate management method and apparatus, computer device, and storage medium
US11038771B2 (en) Systems, methods, and apparatuses for implementing a metadata driven rules engine on blockchain using distributed ledger technology (DLT)
EP3438903B1 (en) Hierarchical network system, and node and program used in same
US11438139B2 (en) Blockchain based secure naming and update verification
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
JP7029408B2 (ja) 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
JP6877448B2 (ja) 分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム
US9286369B2 (en) Data replication across enterprise boundaries
US9967334B2 (en) Computing device configuration and management using a secure decentralized transaction ledger
US20200145373A1 (en) System for blockchain based domain name and ip number register
Choi et al. Blockchain-based distributed firmware update architecture for IoT devices
CN111144881A (zh) 对资产转移数据的选择性访问
EP3543853A1 (en) Providing microservice information
JP2020517200A (ja) Ｕｔｘｏ基盤プロトコルを利用したブロックチェーン基盤の文書管理方法及びこれを利用した文書管理サーバ｛ｍｅｔｈｏｄ ｆｏｒ ｍａｎａｇｉｎｇ ｄｏｃｕｍｅｎｔ ｏｎ ｂａｓｉｓ ｏｆ ｂｌｏｃｋｃｈａｉｎ ｂｙ ｕｓｉｎｇ ｕｔｘｏ−ｂａｓｅｄ ｐｒｏｔｏｃｏｌ，ａｎｄ ｄｏｃｕｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ ｕｓｉｎｇ ｓａｍｅ｝
KR20200106000A (ko) 블록체인-기반 디지털 인증서를 구현하기 위한 시스템 및 방법
JP2022504348A (ja) ブロックチェーン・リソースを格納するブロックチェーン通知ボード
WO2022121538A1 (zh) 基于区块链的数据同步方法、系统及相关设备
CN111294379B (zh) 区块链网络服务平台及其权限托管方法、存储介质
KR20200105999A (ko) 디지털 마크를 생성하기 위한 시스템 및 방법
EP4002786B1 (en) Distributed ledger system
WO2022004854A1 (ja) 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム
WO2019142884A1 (ja) ブロック検証装置、ブロック検証方法、及びプログラム
CN110866289A (zh) 基于区块链的数据处理方法、装置、服务器及存储介质
CN111488626A (zh) 基于区块链的数据处理方法、装置、设备及介质
JP2023544518A (ja) オペレーティングシステムを公開するためのブロックチェーンベースのシステムおよび方法

Legal Events

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

Ref document number: 20942918

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022532921

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20942918

Country of ref document: EP

Kind code of ref document: A1