WO2022102418A1 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

情報処理装置、情報処理方法及び情報処理プログラム Download PDF

Info

Publication number
WO2022102418A1
WO2022102418A1 PCT/JP2021/039765 JP2021039765W WO2022102418A1 WO 2022102418 A1 WO2022102418 A1 WO 2022102418A1 JP 2021039765 W JP2021039765 W JP 2021039765W WO 2022102418 A1 WO2022102418 A1 WO 2022102418A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
proof
data
viewing authority
blockchain
Prior art date
Application number
PCT/JP2021/039765
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 JP2022561813A priority Critical patent/JPWO2022102418A1/ja
Priority to US18/251,541 priority patent/US20240015021A1/en
Publication of WO2022102418A1 publication Critical patent/WO2022102418A1/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/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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • 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
    • 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
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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 information processing device, an information processing method, and an information processing program.
  • a distributed ledger system also known as a blockchain system, is used to manage various transaction information exchanged over the network.
  • Patent Document 1 proposes a technique in which an auditing device audits and traces transaction information (sender, recipient, amount, etc.) of virtual currency described on a distributed ledger.
  • a transaction (transaction information) with zero-knowledge proof is used in order to anonymize the transaction information.
  • transaction information transaction information
  • zero-knowledge proof is used in order to anonymize the transaction information.
  • "zk-snarks" is known as a technique based on zero-knowledge proof.
  • the information processing apparatus of one form according to the present disclosure includes a first recording unit, a verification unit, and a second recording unit.
  • the first recording unit records information on the data viewing authority in the blockchain in response to a request from the information management device that manages the data.
  • the verification unit verifies the zero-knowledge proof proof to prove that the user is a legitimate user who has the viewing authority based on the information about the viewing authority written in the blockchain.
  • the second recording unit records information on the proof verification result on the blockchain.
  • the blockchain distributed ledger system
  • transaction history such as virtual currency
  • ZKP Zero-Knowledge Proof
  • Zero-knowledge proof is a protocol for convincing that something is correct (the proposition is true). By using zero-knowledge proof, it is possible to prove that we know it without disclosing information that we do not want to know. Therefore, by recording the transaction history using the zero-knowledge proof in the blockchain, privacy can be ensured without impairing the verifiability of the distributed ledger.
  • FIG. 12 is a diagram showing an outline of zero-knowledge proof using "Merkle Tree”.
  • H (Y 0 )” to “H (Y 3 )” in FIG. 12 indicate hash values written to the blockchain.
  • “a 0, 0 “, “a 0 , 1”, “A 0 “, “A 1 “, “outh 0 “, “outh 1 “, and “R 0 “ are "Merkle Tree”, respectively. Shows the nodes that make up the tree structure.
  • the zero-knowledge proof using "Merkle Tree” realizes high anonymity, but on the other hand, the amount of calculation for the zero-knowledge proof is large, and it may take time to verify the proposition. For example, when creating a tree structure as illustrated in FIG. 12, if the number of layers until reaching the node of the root is large, the amount of calculation increases accordingly. Therefore, when the transaction information recorded in the blockchain is anonymized by zero-knowledge proof, there is a problem that it is difficult to promptly provide the service. This problem becomes a particular problem in, for example, a service for conducting face-to-face transactions. Therefore, the present disclosure proposes an information processing device, an information processing method, and an information processing program that can realize prompt service provision while ensuring anonymity.
  • FIG. 1 is a schematic diagram showing a system configuration example according to the embodiment of the present disclosure.
  • the information processing system 1 according to the embodiment of the present disclosure includes a user terminal 10, a service providing device 20, a BC client device 30, a BC system 40, and a data user device 50. ..
  • the configuration of the information processing system 1 is not particularly limited to the example shown in FIG. 1, and more user terminals 10 than shown in FIG. 1, a service providing device 20, a BC client device 30, and a BC system are not particularly limited. 40 or the data user device 50 may be included.
  • the user terminal 10, the service providing device 20, the BC client device 30, the BC system 40, and the data user device 50 are connected to the network N by wire or wirelessly.
  • the network N includes a LAN (Local Area Network), a WAN (Wide Area Network), a telephone network (mobile phone network, fixed telephone network, etc.), a regional IP (Internet Protocol) network, the Internet, and the like.
  • the user terminal 10 and the service providing device 20 can communicate with each other via the network N.
  • the service providing device 20 and the BC client device 30 can communicate with each other via the network N.
  • the service providing device 20 and the data user device 50 can communicate with each other via the network N.
  • the BC client device 30 and the BC system 40 can communicate with each other via the network N.
  • the user terminal 10 is, for example, an information processing device used by a user who entrusts personal information to the service providing device 20.
  • the user terminal 10 can be realized by a smartphone, a tablet terminal, a notebook PC (Personal Computer), a desktop PC, a mobile phone, a PDA (Personal Digital Assistant), or the like.
  • the service providing device 20 (an example of an information management device) is an information processing device that manages personal information uploaded by a user of the user terminal 10 by using the user terminal 10. Further, the service providing device 20 grants, for example, the user of the data user device 50, which is the data request source of the personal information, the right to view the personal information. Further, the service providing device 20 receives a proof of zero-knowledge proof from the user of the data user device 50, which is a data request source of personal information, and provides personal information based on the verification result of the received proof.
  • the service providing device 20 can be realized by a server or the like.
  • the BC client device 30 is an information processing device that records data to the BC system 40 in response to a request from the service providing device 20.
  • the BC client device 30 may be physically or functionally integrated into the BC system 40 described below. Further, the BC client device 30 may be distributed from the BC system 40.
  • the BC client device 30 can be realized by a server or the like. The processing of the BC client device 30 will be described later.
  • the BC system 40 is an information processing device that manages each block that collects data such as information related to viewing authority of personal information and information related to proof verification results accompanying a request for personal information as a block chain configured by connecting them in the order of processing. be.
  • the BC system 40 is composed of a plurality of information processing devices (nodes) that execute various processes such as block generation and block chain sharing, for example.
  • Each node of the BC system 40 includes, for example, a communication unit realized by a NIC (Network Interface Card), a communication circuit, or the like, and is connected to the network N by wire or wirelessly.
  • the BC system 40 assumes a permission-type blockchain that can be used by the service providing device 20 and the data user device 50, but any configuration can be realized as long as the processing according to the embodiment of the present disclosure can be realized. May be.
  • the data user device 50 is an information processing device used by a user who acquires personal information managed by the service providing device 20.
  • the data user device 50 can be realized by a smartphone, a tablet terminal, a notebook PC, a desktop PC, a mobile phone, a PDA, or the like.
  • the data user device 50 generates a zero-knowledge proof proof for proving that the user is a legitimate user who has been granted the right to view personal information from the service providing device 20.
  • the data user device 50 acquires desired personal information from the service providing device 20 by transmitting a data request for personal information to the service providing device 20 together with the generated proof.
  • FIG. 2 is a schematic diagram showing an example of information processing according to the embodiment of the present disclosure.
  • the user terminal 10 transmits personal information to the service providing device 20 (step S11).
  • the service providing device 20 manages personal information received from the user terminal 10 in a local environment (step 12).
  • the data user device 50 transmits a request for acquisition of viewing authority for viewing personal information to the service providing device 20 (step S13).
  • the service providing device 20 receives the viewing authority acquisition request from the data user device 50, the service providing device 20 transmits a viewing authority recording request to the BC client device 30 (step S14).
  • the BC client device 30 records information regarding viewing authority in the BC system 40 in response to a request from the service providing device 20 (step S15).
  • the information regarding the viewing authority recorded by the BC client device 30 in the BC system 40 is information indicating that the user of the data user device 50 is permitted to view the personal information, and is composed of an arbitrary character string or the like. can.
  • the BC client device 30 can record the hash value obtained by hashing the information related to the viewing authority in the BC system 40, instead of recording the information related to the viewing authority in the BC system 40 as it is.
  • the service providing device 20 assigns the viewing authority to the data user device 50 after recording the viewing authority by the BC client device 30 (step S16).
  • the service providing device 20 provides the data user device 50 with a secret value (random number or the like) incorporated when hashing the viewing authority, together with information regarding the viewing authority.
  • the secret value may be a nonce.
  • the data user device 50 When the viewing authority is granted by the service providing device 20, the data user device 50 generates a zero-knowledge proof proof for proving that the user is a legitimate user who has been granted the viewing authority for personal information (step). S17). As a proof created by the data user apparatus 50, evidence is assumed that the BC client apparatus 30 can produce the same hash value as the hash value recorded in the BC system 40 in response to a request from the service providing apparatus 20. For example, the data user device 50 may present the hash value itself generated by using the secret value given by the service providing device 20 to the service providing device 20 as a proof. Then, the data user device 50 transmits a data request for personal information to the service providing device 20 together with the generated proof (step S18).
  • the service providing device 20 When the service providing device 20 receives the data request from the data user device 50, the service providing device 20 transmits a proof confirmation request to the BC client device 30 (step S19).
  • the BC client device 30 executes proof verification in response to a proof confirmation request received from the service providing device 20 (step S20). Specifically, the BC client device 30 compares the hash value of the information related to the browsing record recorded in the BC system 40 with the hash value based on the proof acquired from the service providing device 20, and determines whether or not they match. ..
  • the BC client device 30 records the proof verification result in the BC system 40 as a usage history (step S21). Specifically, the BC client device 30 records in the BC system 40 information regarding the verification result of the proof indicating whether or not the proof acquired from the data user device 50 is valid. At this time, the BC client device 30 has the viewing authority so that the record position of the information related to the viewing authority recorded in the BC system 40 and the proof generated in the data user device 50 are not associated with each other at the time of verifying the proof. The usage history is recorded except for the record position. Further, the BC client device 30 transmits the proof verification result to the service providing device 20 as a determination result (step S22).
  • the service providing device 20 provides personal information corresponding to the data request (see step S18) received from the data user device 50 to the data user device 50 based on the proof determination result received from the BC client device 30. (Step S23).
  • the BC client device 30 compares the information (hash value) regarding the viewing authority recorded in advance in the BC system 40 with the hash value based on the proof generated in the data user device 50. , Verify the proof.
  • zero-knowledge proof using "Merkle Tree” all the data necessary for calculating the hash value is acquired from the block data recorded in the blockchain, and the hash value is calculated up to the root node using the acquired data.
  • the hash value needs to be calculated only once in the data user apparatus 50, and only the comparison between the generated hash value and the recorded hash value is required. It's done. This makes it possible to promptly provide services (provide personal information).
  • the BC client device 30 records the verification result in the BC system 40
  • the information (hash value) regarding the viewing authority on the BC system 40 used at the time of verifying the proof and the proof generated in the data user device 50 Do not record the information associated with.
  • the BC system 40 (blockchain) anonymity equivalent to that of "Merkle Tree" can be realized. Therefore, according to the embodiment of the present disclosure, it is possible to realize prompt service provision while ensuring anonymity.
  • FIGS. 3 and 4. are schematic views showing an outline of the service form according to the embodiment of the present disclosure.
  • FIG. 3 shows a service form in which the medical service ⁇ provides the biometric information and medical data of the user managed by the medical service ⁇ to doctors, medical institutions, etc. who are data users.
  • the user shown in FIG. 3 corresponds to the user of the user terminal 10 shown in FIGS. 1 and 2.
  • the medical service ⁇ shown in FIG. 3 corresponds to the service providing device 20 shown in FIGS. 1 and 2.
  • the blockchain shown in FIG. 3 corresponds to the BC client device 30 and the BC system 40 shown in FIGS. 1 and 2.
  • the data user shown in FIG. 3 corresponds to the user of the data user device 50 shown in FIGS. 1 and 2.
  • the user can use the electrocardiogram, heart rate, blood pressure, body temperature, and other biological information (vital signs) that can be measured with a predetermined measuring device, medical records at medical institutions, and medical data such as health diagnosis results as medical service ⁇ . Upload and pre-register.
  • Medical service ⁇ registers and manages biological information and medical data uploaded by users as personal information. When registering biometric information or medical data, the medical service ⁇ inquires whether or not to consent to the provision of data to doctors and medical institutions. The medical service ⁇ may allow the registration of personal information on condition that the data is provided. The medical service ⁇ records information on the viewing authority of personal information in the blockchain in response to a request from the data user, and grants the viewing authority to the data user.
  • the data user generates a proof of zero-knowledge proof based on the viewing authority, and sends the data request to the medical service ⁇ together with the generated proof.
  • the medical service ⁇ acquires personal information corresponding to the data request based on the verification result of the proof included in the data request received from the data user, and provides the acquired personal information to the data user. In addition, the medical service ⁇ records the usage history of the viewing authority in the blockchain.
  • FIG. 4 shows a service form in which the data sharing service X provides personal information and the like managed by itself to data users and the like.
  • the user shown in FIG. 4 corresponds to the user of the user terminal 10 shown in FIGS. 1 and 2.
  • the data sharing services X, Y, and Z shown in FIG. 4 correspond to the service providing device 20 shown in FIGS. 1 and 2.
  • the blockchain shown in FIG. 4 corresponds to the BC client device 30 and the BC system 40 shown in FIGS. 1 and 2.
  • the data user shown in FIG. 4 corresponds to the user of the data user device 50 shown in FIGS. 1 and 2.
  • the data sharing services X, Y, and Z shown in FIG. 4 have the same functions.
  • an example of a service executed via the data sharing service X will be described.
  • the user uploads information on demographic attributes such as age, gender, and gender, location information, and data such as application usage history to the data sharing service X and registers them in advance.
  • Data sharing service X registers and manages personal information uploaded by users. When registering personal information, the data sharing service X inquires whether or not he / she agrees to provide data to the data user. The data sharing service X may allow the registration of personal information on condition that the data provision is agreed. The data sharing service X records information on the viewing authority of personal information in the blockchain in response to a request from the data user, and grants the viewing authority to the data user.
  • the data user generates a proof of zero-knowledge proof based on the viewing authority, and sends the data request to the data sharing service X together with the generated proof.
  • the data sharing service X acquires personal information corresponding to the data request based on the verification result of the proof included in the data request received from the data user, and provides the acquired personal information to the data user. In addition, the data sharing service X records the usage history of personal information on the blockchain. Further, when the data sharing service X gives the user a reward according to the use of personal information, the data sharing service X may record the information about the reward according to the blockchain.
  • the information processing system 1 can be applied to various services related to the provision of personal information as described above.
  • FIG. 5 is a block diagram showing a configuration example of the BC client device according to the embodiment of the present disclosure.
  • the BC client device 30 is an information processing device that executes data recording or the like on the blockchain in response to a request from the service providing device 20.
  • the BC client device 30 may be one of the information processing devices constituting the BC system 40, or may be an information processing device independent of the BC system 40.
  • the BC client device 30 has a communication unit 31, a storage unit 32, and a control unit 33.
  • the communication unit 31 is realized by a NIC (Network Interface Card), various communication modems, and the like.
  • the communication unit 31 communicates with the service providing device 20 via the network N, and transmits / receives various information.
  • the storage unit 32 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory (Flash Memory), or a storage device such as a hard disk or an optical disk.
  • the storage unit 32 can store, for example, programs and data for realizing various processing functions executed by the control unit 33.
  • the program stored in the storage unit 32 includes a program for realizing a processing function corresponding to each unit of the control unit 33.
  • the program stored in the storage unit 32 includes an OS (Operating System) and various application programs.
  • the control unit 33 has a first recording unit 331, a verification unit 332, a second recording unit 333, and a transmission unit 334.
  • Each functional unit included in the control unit 33 is realized by a control circuit including a processor and a memory.
  • Each functional unit included in the control unit 33 is realized, for example, by executing an instruction written in a program read from the internal memory by the processor with the internal memory as a work area.
  • the programs that the processor reads from the internal memory include the OS (Operating System) and application programs.
  • each functional unit included in the control unit 33 may be realized by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array).
  • main storage device and auxiliary storage device that function as the internal memory described above are realized by, for example, a semiconductor memory element such as RAM (Random Access Memory) or flash memory (Flash Memory), or a storage device such as a hard disk or an optical disk. Will be done.
  • a semiconductor memory element such as RAM (Random Access Memory) or flash memory (Flash Memory)
  • flash memory Flash Memory
  • storage device such as a hard disk or an optical disk. Will be done.
  • the first recording unit 331 records information on the data viewing authority in the BC system 40 in response to a request from the service providing device 20 that manages the data. For example, when the first recording unit 331 receives the recording request of the viewing authority from the service providing device 20, the hash value included in the recording request is written in the BC system 40 and recorded.
  • the hash value generated by the service providing device 20 is information about the viewing authority given to the requester of the viewing authority by the service providing device 20 using "HMAC (Hash-based Message Authentication Code)" and the service providing device 20. It is generated using a secret value that is shared exclusively with the requester of viewing authority and a public key provided by the requester of viewing authority.
  • Hash function As a hash function used when generating a hash value, in addition to "HMAC (Hash-based Message Authentication Code)", "SHA-256 (Secure Hash Algorithm 256-bit)", “Pedersen Commission”, etc. are optional. Hash function can be used.
  • the verification unit 332 verifies the proof of zero-knowledge proof for proving that the user is a legitimate user who has the viewing authority, based on the information regarding the viewing authority written in the blockchain. Specifically, when the verification unit 332 receives the proof confirmation request from the service providing device 20, the verification unit 332 receives information on the viewing authority from the BC system 40 based on the writing position (record position) of the viewing authority included in the confirmation request. Get the keyed hash value. The verification unit 332 verifies the proof by comparing the acquired keyed hash value with the keyed hash value generated based on the proof included in the confirmation request. If the hash values are the same, the verification unit 332 determines that the user is a legitimate user having viewing authority.
  • the second recording unit 333 records the information regarding the verification result of the proof by the verification unit 332 in the BC system 40.
  • the second recording unit 333 does not record the information linking the information regarding the proof and the viewing authority.
  • the second recording unit 333 writes the information other than the writing position (record position) of the information related to the viewing authority used for the verification of the proof among the information related to the verification of the proof to the BC system 40.
  • the transmission unit 334 transmits the determination result of whether or not the data request source is a legitimate user having viewing authority to the service providing device 20.
  • FIG. 6 is a sequence diagram showing an example of the processing procedure according to the comparative example.
  • the user terminal 10EX transmits personal information to the service providing device 20EX (step S101).
  • the service providing device 20EX writes and records the ownership of the personal information in the BC system 40EX (step S102).
  • the data user device 50EX transmits a request for acquisition of the viewing authority of personal information to the service providing device 20EX (step S103).
  • the service providing device 20EX confirms the content of the viewing authority acquisition request (step S104), and records the viewing authority for the BC system 40EX (step S105). Then, the service providing device 20EX grants the viewing authority to the data user device 50EX (step S106).
  • the data user device 50EX transmits a request for a record to be used for "Merkle Tree" to the BC system 40EX (step S107).
  • the BC system 40EX passes the record used for "Merkle Tree” to the data user device 50EX in response to the request from the data user device 50EX (step S108).
  • the data user device 50EX creates a zero-knowledge proof of viewing authority incorporating "Merkle Tree" (step S109). Then, the data user device 50EX transmits a zero-knowledge proof proof to the service providing device 20EX together with the data request of the personal information (step S110).
  • the service providing device 20EX confirms the proof of zero-knowledge proof (step S111), writes the usage history to the BC system 40, and records it (step S112). Then, when the user of the data user device 50EX has a legitimate viewing authority, the service providing device 20EX provides the personal information corresponding to the data request to the user of the data user device 50EX (step S113).
  • FIG. 7 is a sequence diagram showing an example of the processing procedure according to the embodiment of the present disclosure.
  • the user terminal 10 transmits personal information to the service providing device 20 (step S201).
  • the service providing device 20 transmits a request for recording the ownership of personal information to the BC client device 30 (step S202).
  • the BC client device 30 writes and records in the BC system 40 that it has ownership of personal information in response to a request from the service providing device 20 (step S203).
  • the data user device 50 transmits a request for acquisition of the viewing authority of personal information to the service providing device 20 (step S204).
  • the data user device 50 creates a key pair of a public key and a private key in advance, and provides the public key to the service providing device 20 when requesting the service providing device 20 to acquire viewing authority.
  • the service providing device 20 confirms the content of the viewing authority acquisition request (step S205), and transmits a viewing authority recording request to the BC client device 30 (step S206).
  • the service providing device 20 generates a hash value of information regarding the viewing authority, includes it in the recording request of the viewing authority, and transmits the hash value.
  • This hash value is a secret value that is limitedly shared between the information related to the viewing authority and the data user device 50 that is the requesting source of the viewing authority: "r" and the data usage that is the requesting source of the viewing authority. Generated using the public key provided by the person device 50.
  • the BC client device 30 writes and records information (hash value) regarding viewing authority in the BC system 40 in response to a request from the service providing device 20 (step S207). Then, the BC client device 30 returns the writing position (record position) of the information related to the viewing authority to the service providing device 20 (step S208).
  • the service providing device 20 grants viewing authority to the data user device 50 (step S209).
  • the service providing device 20 provides the data user device 50 with a secret value: "r" and a writing position (record position) of a hash value of information related to the viewing authority in the BC system 40 as viewing authority.
  • the data user device 50 creates a zero-knowledge proof of viewing authority (step S210). Specifically, the data user device 50 inputs the private key paired with the public key provided to the service providing device 20 into the public key generation function to generate the public key. The data user device 50 generates a hash value from a hash function based on the generated public key, a secret value provided by the service providing device 20: "r", and information on viewing authority. Zero-knowledge proof. Create a proof of. Then, the data user device 50 transmits the proof of zero-knowledge proof and the writing position (record position) of the viewing authority to the service providing device 20 together with the data request of the personal information (step S211).
  • the service providing device 20 transmits a proof confirmation request to the BC client device 30 (step S212).
  • the BC client device 30 verifies the proof of the data user device 50 in response to a request from the service providing device 20 (step S213). Specifically, the BC client device 30 transfers the hash value recorded in the browsing information writing position (record position) included in the data request transmitted from the data user device 50 to the service providing device 20 from the BC system 40. get.
  • the BC client device 30 verifies the proof of the data user device 50 by comparing the hash value acquired from the BC system 40 with the hash value created based on the proof of the data user device 50.
  • the BC client device 30 writes and records information regarding the proof verification result in the BC system 40 as a usage history (step S214). At this time, the BC client device 30 obtains information relating to the hash value on the BC system 40 used for the verification of the proof and the hash value generated based on the proof among the information regarding the verification result of the proof. Do not record in system 40. Then, the BC client device 30 returns a determination result as to whether or not the user of the data user device 50 has a legitimate viewing authority to the service providing device 20 (step S215).
  • the service providing device 20 passes the personal information corresponding to the data request to the data user device 50 when the user of the data user device 50 has a legitimate viewing authority. (Step S216).
  • the amount of calculation is calculated.
  • the processing up to the provision of personal information may be delayed. For example, it may take time to acquire the block data recorded in the block chain in the above-mentioned steps S107 and S108, to create the proof in the above-mentioned step 109, and to create the tree structure in the above-mentioned step S111.
  • the BC client device 30 provides a zero-knowledge proof proof for proving that the user of the data user device 50 has a legitimate viewing authority. Verify.
  • This proof incorporates a hash value generated using a secret value: "r" that is limitedly shared between the service providing device 20 and the data user device 50.
  • the BC client device 30 is required to calculate the time required to acquire the block data required for the verification of the proof from the blockchain and the hash value to be repeatedly executed up to the root node. Time and the like are not required, and processing can be made faster than using "Merkle Tree".
  • FIG. 7 the processing procedure according to the embodiment of the present disclosure (see FIG.
  • the BC client device 30 when the BC client device 30 records the information regarding the verification result of the proof on the blockchain, the BC client device 30 provides information relating the proof and the information regarding the viewing authority. Do not record. As a result, anonymity equivalent to that of "Merkle Tree" can be realized on the blockchain.
  • the information processing system 1 By arranging the BC client device 30 between the service providing device 20 and the BC system 40, even if there is a new entry into the blockchain operated by the BC system 40, the information processing system 1 can be used. Availability can be increased. That is, when the service providing device 20 directly participates in the blockchain, it is necessary to communicate with other participants in order to fulfill the function of the distributed ledger.
  • the BC client device 30 can be used. By separating the dependency from the service providing device 20, other blockchain participants can continue to provide the service.
  • FIG. 8 is a sequence diagram showing an example of the processing procedure according to the modified example of the present disclosure. Of the processes shown in FIG. 8, the processes of step S310, step S311, step S314, and step S316 are different from the processes shown in FIG. 7.
  • the user terminal 10 transmits personal information to the service providing device 20 (step S301).
  • the service providing device 20 transmits a request for recording the ownership of personal information to the BC client device 30 (step S302).
  • the BC client device 30 writes and records in the BC system 40 that it has the ownership of personal information in response to a request from the service providing device 20 (step S303).
  • the data user device 50 transmits a request for acquisition of the viewing authority of personal information to the service providing device 20 (step S304).
  • the service providing device 20 confirms the content of the viewing authority acquisition request (step S305), and transmits a viewing authority recording request to the BC client device 30 (step S306).
  • the BC client device 30 writes and records information (hash value) regarding viewing authority in the BC system 40 in response to a request from the service providing device 20 (step S307). Then, the BC client device 30 returns the writing position (record position) of the information related to the viewing authority to the service providing device 20 (step S308). The service providing device 20 grants viewing authority to the data user device 50 (step S309).
  • the data user device 50 creates a zero-knowledge proof of viewing authority, and also creates a new secret value and a new hash value based on the new secret value (step S310). Then, the data user device 50 transmits the proof of zero-knowledge proof, the writing position (record position) of the viewing authority, and the new hash value to the service providing device 20 together with the data request of the personal information (step S311). By sending a hash value based on the new secret value instead of the new secret value, security against man-in-the-middle attacks can be ensured.
  • the service providing device 20 transmits a proof confirmation request to the BC client device 30 (step S312). Further, the service providing device 20 sends a new hash value received from the data user device 50 to the BC client device 30 together with the proof confirmation request.
  • the BC client device 30 verifies the proof of the data user device 50 in response to a request from the service providing device 20 (step S313). Further, the BC client device 30 writes and records information regarding the proof verification result in the BC system 40 as a usage history, and updates the viewing authority with a new hash value received from the service providing device 20 (step S314). As a result, the next time the data is used, the data request using the old proof will not be accepted.
  • the BC client device 30 returns the determination result of whether or not the user of the data user device 50 has the proper viewing authority to the service providing device 20 (step S315). At this time, the BC client device 30 sends the write position (record position) of the updated information (new hash value) regarding the viewing authority to the service providing device 20.
  • the service providing device 20 Based on the determination result acquired from the BC client device 30, the service providing device 20 has updated viewing authority along with personal information corresponding to the data request when the user of the data user device 50 has a legitimate viewing authority.
  • the writing position (record position) of is passed to the data user device 50 (step S316).
  • the new secret value created in step S310 which is the source of the new hash value transmitted to the service providing device 20 in step S311, is used.
  • the BC client device 30 always uses the latest hash value and rejects the proof based on the old hash value.
  • the BC client device 30 may record a revolving list listing the targets for which the viewing authority is revoked in the BC system 40.
  • FIG. 9 is a block diagram showing a configuration example of the BC client device according to the modified example of the present disclosure.
  • the BC client device 30 according to the modified example is different from the above embodiment in that it has an update unit 335.
  • the update unit 335 updates the revolving list recorded in the BC system 40 in response to a request from the service providing device 20. Prior to the verification of the proof, the verification unit 332 verifies whether or not the proof of the proof is included in the revolving list.
  • FIG. 10 is a sequence diagram showing an example of the processing procedure according to the modified example of the present disclosure. Note that FIG. 10 shows an example of the processing flow when the user of the data user device 50 is the target for revoking the viewing authority (target for revoking).
  • the user terminal 10 transmits a revoked request to the service providing device 20 (step S401).
  • the service providing device 20 transfers the revoked request to the BC client device 30 (step S402).
  • the BC client device 30 updates the revolving list recorded in the BC system 40 in response to the revolving request received from the service providing device 20 (step S403).
  • the data user device 50 transmits the proof of zero-knowledge proof, the writing position (record position) of the viewing authority, and the new secret value to the service providing device 20 together with the data request of the personal information (step S404).
  • the service providing device 20 transmits a proof confirmation request to the BC client device 30 (step S405).
  • the BC client device 30 Upon receiving the proof confirmation request from the service providing device 20, the BC client device 30 confirms the revolving list and verifies the proof (step S406).
  • the BC client device 30 does not execute proof verification when the user of the data user device 50 falls under the revolving target of the revolving list.
  • the BC client device 30 refers to the revolving list recorded in the BC system 40, and confirms whether or not the proof proofer (user of the data user device 50) is the target of revolving. .. Then, when the proof proofer is the target of the revokes, the BC client device 30 returns a reject (that is the target of the revokes) to the service providing device 20 as a determination result without executing the verification of the proof (step S407). ). If the proof proofer does not fall under the revolving target of the revolving list, the BC client device 30 executes the proof verification in the same manner as in the above embodiment.
  • the service providing device 20 notifies the user of the data user device 50 that it has been rejected based on the verification result received from the BC client device 30 (step S408).
  • the BC client device 30 may be realized by a dedicated computer system or a general-purpose computer system.
  • a computer-readable recording medium such as an optical disk, a semiconductor memory, a magnetic tape, or a flexible disk can be used to provide various programs for realizing the information processing method executed by the BC client device 30 according to the embodiments and modifications of the present disclosure. It may be stored and distributed in such a place.
  • the BC client device 30 according to the embodiment and the modification of the present disclosure can realize the information processing method according to the embodiment and the modification of the present disclosure by installing and executing various programs on the computer.
  • various programs for realizing the information processing method executed by the BC client device 30 according to the embodiment and the modification of the present disclosure are stored in a disk device provided in a server on a network such as the Internet, and a computer is stored. You may be able to download it to. Further, even if the functions provided by various programs for realizing the information processing method executed by the BC client device 30 according to the embodiment and the modification of the present disclosure are realized by the cooperation between the OS and the application program. good. In this case, the part other than the OS may be stored in a medium and distributed, or the part other than the OS may be stored in the application server so that it can be downloaded to a computer or the like.
  • each component of the BC client device 30 is a functional concept, and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or part of them may be functionally or physically distributed / physically in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • the verification unit 332 and the second recording unit 333 of the control unit 33 of the BC client device 30 may be functionally integrated and configured.
  • FIG. 11 is a block diagram showing a hardware configuration example of a computer capable of realizing a BC client device according to an embodiment and a modification of the present disclosure. Note that FIG. 11 shows an example of a computer, and is not limited to the configuration shown in FIG.
  • the BC client device 30 can be realized by, for example, a computer 1000 having a processor 1001, a memory 1002, and a communication module 1003.
  • the processor 1001 is typically a CPU (Central Processing Unit), a DSP (Digital Signal Processor), a SoC (System-on-a-Chip), a system LSI (Large Scale Integration), or the like.
  • CPU Central Processing Unit
  • DSP Digital Signal Processor
  • SoC System-on-a-Chip
  • LSI Large Scale Integration
  • the memory 1002 is typically a RAM (Random Access Memory), a ROM (Read Only Memory), a non-volatile or volatile semiconductor memory such as a flash memory, or a magnetic disk.
  • the storage unit 32 included in the BC client device 30 is realized by the memory 1002.
  • the communication module 1003 is typically a communication card for wired or wireless LAN (Local Area Network), LTE (Long Term Evolution), Modem (registered trademark), WUSB (Wireless USB), and optical communication. Routers and various communication modems.
  • the function of the communication unit 31 of the BC client device 30 according to the above embodiment is realized by the communication module 1003.
  • the processor 1001 functions as, for example, an arithmetic processing unit or a control device, and controls all or a part of the operation of each component based on various programs recorded in the memory 1002.
  • Each functional unit (first recording unit 331, verification unit 332, second recording unit 333, transmission unit 334, and update unit 335) of the BC client device 30 is an instruction for the processor 1001 to operate as each functional unit. Is realized by reading the information processing program in which is described from the memory 1002 and executing it.
  • the processor 1001 and the memory 1002 realize information processing by each functional unit of the BC client device 30 in cooperation with software (information processing program stored in the memory 1002).
  • the BC client device 30 (an example of an information processing device) according to the embodiment of the present disclosure includes a first recording unit 331, a verification unit 332, and a second recording unit 333.
  • the first recording unit 331 receives information regarding the viewing authority of data (for example, personal information) in response to a request from the service providing device 20 (an example of an information management device) that manages data, and provides information regarding the viewing authority of the data (for example, personal information) to the BC system 40 (an example of a blockchain).
  • the verification unit 332 verifies the zero-knowledge proof proof for proving that the user is a legitimate user who has been granted the viewing authority, based on the information regarding the viewing authority written in the BC system 40.
  • the second recording unit 333 records the information regarding the verification result of the proof in the BC system 40. Therefore, the BC client device 30 can realize prompt service provision while ensuring anonymity.
  • the first recording unit 331 is a secret information (for example, secret information: ", for example, secret information shared between a data requester requesting data (for example, a user of the data user device 50) and the service providing device 20".
  • secret information for example, secret information: ", for example, secret information shared between a data requester requesting data (for example, a user of the data user device 50) and the service providing device 20".
  • r a hash value obtained by hashing information regarding viewing authority (for example, an arbitrary character string) is recorded in the BC system 40. This makes it possible to track the usage history without directly recording personal information on the blockchain.
  • the second recording unit 333 records the information regarding the verification result of the proof on the blockchain, the information relating the proof and the information regarding the viewing authority is not recorded.
  • the BC system 40 blockchain
  • the second recording unit 333 updates the information regarding the viewing authority and records it in the BC system 40 every time the verification unit 332 performs the verification. This makes it possible to prevent reuse of the proof due to data interception.
  • the BC client device 30 further includes an update unit 335 that updates the revolving list recorded in the BC system 40 in response to a request from the service providing device 20. Further, the verification unit 332 verifies whether or not the proof proofer is included in the revolving list prior to the verification of the proof. This makes it possible to avoid verification of the proof of the data user who does not want the user to disclose personal information.
  • the technique of the present disclosure can be configured as follows, assuming that it belongs to the technical scope of the present disclosure.
  • the first recording unit that records the information related to the viewing authority of the data in the blockchain, and A verification unit that verifies the proof of zero-knowledge proof to prove that the user is a legitimate user who has been granted the viewing authority based on the information about the viewing authority written in the blockchain.
  • An information processing device having a second recording unit that records information on the verification result of the proof on the blockchain.
  • the first recording unit is The hash value obtained by hashing the information related to the viewing authority is recorded in the blockchain using the secret information shared between the data requester requesting the data and the information management device (1). The information processing device described.
  • the second recording unit is The information processing device according to (1) or (2) above, which does not record information relating to the proof and the information relating to the viewing authority when recording the information regarding the verification result of the proof in the blockchain.
  • the second recording unit is The information processing apparatus according to any one of (1) to (3), wherein the information regarding the viewing authority is updated and recorded in the block chain each time the verification unit performs verification.
  • the verification unit The information processing apparatus according to (1) above, which verifies whether or not the certifier of the proof is included in the revolving list prior to the verification of the proof.
  • the processor In response to a request from the information management device that manages the data, information regarding the viewing authority of the data is recorded in the blockchain. Based on the information about the viewing authority written in the blockchain, a zero-knowledge proof proof for proving that the user is a legitimate user who has been granted the viewing authority is verified. An information processing method for recording information regarding the verification result of the viewing authority in the blockchain. (7) To the processor In response to a request from the information management device that manages the data, the blockchain is made to record the information related to the viewing authority of the data. Based on the information about the viewing authority written in the blockchain, the zero-knowledge proof proof for proving that the user is a legitimate user who has been granted the viewing authority is verified. An information processing program that records information about the verification result of the viewing authority in the blockchain.
  • Information processing system 10 User terminal 20 Service providing device 30 BC Client device 31 Communication unit 32 Storage unit 33 Control unit 40 BC system 50 Data user device 331 1st recording unit 332 Verification unit 333 2nd recording unit 334 Transmission unit 335 Update Department

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

情報処理装置（３０）は、第１記録部（３３１）と、検証部（３３２）と、第２記録部（３３３）とを備える。第１記録部（３３１）は、データを管理する情報管理装置（２０）からの要求に応じて、データの閲覧権限に関する情報をブロックチェーンに記録する。検証部（３３２）は、ブロックチェーンに書き込まれた閲覧権限に関する情報に基づいて、閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する。第２記録部（３３３）は、プルーフの検証結果に関する情報をブロックチェーンに記録する。

Description

情報処理装置、情報処理方法及び情報処理プログラム
　本開示は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
　ブロックチェーンシステムとも称される分散型台帳システムが、ネットワークを通じてやり取りされる様々な取引情報の管理に利用されている。例えば、特許文献１には、監査装置が分散台帳上に記載された仮想通貨の取引情報（送金者や受金者、金額等）の監査及びトレースを実行する技術が提案されている。
　また、前述の技術では、取引情報を匿名化するため、ゼロ知識証明付きのトランザクション（取引情報）が利用されている。例えば、ゼロ知識証明を元にした技術として、「ｚｋ－ｓｎａｒｋｓ」などが知られている。
特開２０１８－７１６８号公報
　しかしながら、ブロックチェーンに記録する取引情報をゼロ知識証明により匿名化する場合、迅速なサービス提供が難しいという課題がある。これは、ゼロ知識証明の処理が完了するまでに、少なからず時間を要することに起因する。
　そこで、本開示では、匿名性を担保しつつ、迅速なサービス提供を実現できる情報処理装置、情報処理方法及び情報処理プログラムを提案する。
　上記の課題を解決するために、本開示に係る一形態の情報処理装置は、第１記録部と、検証部と、第２記録部とを備える。第１記録部は、データを管理する情報管理装置からの要求に応じて、データの閲覧権限に関する情報をブロックチェーンに記録する。検証部は、ブロックチェーンに書き込まれた閲覧権限に関する情報に基づいて、閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する。第２記録部は、プルーフの検証結果に関する情報をブロックチェーンに記録する。
本開示の実施形態に係るシステム構成例を示す模式図である。 本開示の実施形態に係る情報処理の一例を示す模式図である。 本開示の実施形態に係るサービス形態の概要を示す模式図である。 本開示の実施形態に係るサービス形態の概要を示す模式図である。 本開示の実施形態に係るＢＣクライアント装置の構成例を示すブロック図である。 比較例に係る処理手順の一例を示すシーケンス図である。 本開示の実施形態に係る処理手順の一例を示すシーケンス図である。 本開示の変形例に係る処理手順の一例を示すシーケンス図である。 本開示の変形例に係るＢＣクライアント装置の構成例を示すブロック図である。 本開示の変形例に係る処理手順の一例を示すシーケンス図である。 本開示の実施形態及び変形例に係るＢＣクライアント装置を実現可能なコンピュータのハードウェア構成例を示すブロック図である。 「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を用いたゼロ知識証明の概要を示す図である。
　以下に、本開示の実施形態について図面に基づいて詳細に説明する。なお、以下の各実施形態において、同一の部位には同一の数字又は符号を付することにより重複する説明を省略する場合がある。また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の数字又は符号の後に異なる数字又は符号を付して区別する場合もある。
　また、以下に示す項目順序に従って本開示を説明する。
　１．はじめに
　２．システム構成例
　３．情報処理の概要
　４．装置構成例
　５．処理手順例
　６．変形例
　７．その他
　８．ハードウェア構成例
　９．むすび
＜＜１．はじめに＞＞
＜１－１．背景＞
　ブロックチェーン（分散型台帳システム）は、ブロックチェーンに記録されるデータのそれぞれに固有に割り当てられるブロックチェーンアドレスを通じて、仮想通貨などの取引情報の履歴（トランザクション履歴）を追跡できるという性質を有する。その一方で、ブロックチェーンに記録されたトランザクション履歴を消去することが現実的ではなく、プライバシーの問題をはらんでいる。
　このプライバシーの問題に鑑み、ブロックチェーンに記録する取引情報を暗号化することにより、完全に匿名化することも考えられる。しかし、取引情報を完全に匿名化した場合、トランザクション履歴の正当性を検証できなくなり、分散型台帳の安全性が損なわれてしまう。そこで、プライバシーを確保しつつ、分散型台帳の検証性を損なわない方法として注目を浴びているのが、ゼロ知識証明（ＺＫＰ：Zero-Knowledge　Proof）である。
　ゼロ知識証明は、ある事柄が正しいこと（命題が真であること）を納得させるためのプロトコルである。ゼロ知識証明を用いることにより、知られたくない情報を開示することなく、それを知っていることを証明することができる。このため、ゼロ知識証明を用いたトランザクション履歴をブロックチェーンに記録することにより、分散型台帳の検証性を損なうことなく、プライバシーの確保を図ることができる。
＜１－２．既存技術＞
　以下、仮想通貨などの取引情報の匿名化に利用されるゼロ知識証明を実現するための技術の一例として、「ｚｋ－ｓｎａｒｋｓ」において利用される「Ｍｅｒｋｌｅ　Ｔｒｅｅ」について説明する。
　仮想通貨の取引において、担保したい匿名性には、「ａｎｏｎｉｍｉｔｙ」と、「ｕｎｌｉｋａｂｉｌｉｔｙ」とがある。「ａｎｏｎｉｍｉｔｙ」は、１つの取引をどのユーザが行っているか分からないという事を意味する。「ｕｎｌｉｋａｂｉｌｉｔｙ」は、２つの取引において、同じユーザが行っているか判別できないことを意味する。仮想通貨の取引では、前述の２つの匿名性を満たすことにより、「誰と誰がいつ・いくら取引したか」を秘匿しつつ、金銭取引が可能となっている。
　分散型台帳において上記２つの匿名性を満足するためには、ブロックチェーン上のトランザクション履歴にユーザを特定する情報を書き込まないことと、どの記録が誰のどの閲覧権限を使ったかを判別できないようにすることが必要となる。
　「Ｍｅｒｋｌｅ　Ｔｒｅｅ」は、自分の記録を特定することなく、全部のトランザクション履歴の中に、自分の権限の記録があることを示すことが可能である。このため、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を用いたゼロ知識証明を作ることにより、上記２つの匿名性が満たされる。図１２は、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を用いたゼロ知識証明の概要を示す図である。
　図１２における「Ｈ（Ｙ０）」～「Ｈ（Ｙ３）」は、ブロックチェーンに書き込まれるハッシュ値を示している。図１２における「ａ０，０」、「ａ０，１」、「Ａ０」、「Ａ１」、「ａｕｔｈ０」、「ａｕｔｈ１」、「Ｒ０」は、それぞれ、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」の木構造を構成するノードを示している。
　「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を利用することにより、全てのハッシュ値「Ｈ（Ｙ０）」～「Ｈ（Ｙ３）」を使って作成される木構造のルートとなるノード「Ｒ０」の値が正しく算出されるか否かをゼロ知識証明の命題とすることができる。例えば、「ａｕｔｈ０」及び「ａｕｔｈ１」を、検証者と証明者との間でやり取りされる秘密の情報（値）とする。これにより、秘密の情報（値）を知り得る者だけが、木構造のルートとなるノード「Ｒ０」の値を正しく算出できる。このようにして、ブロックチェーンに記録される自分のハッシュ値を特定するための情報を開示することなく、ブロックチェーンの中に自分のハッシュ値が含まれることを証明できる。
　このように、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を用いたゼロ知識証明は、高い匿名性を実現する一方、ゼロ知識証明のための計算量が多く、命題の検証に時間がかかってしまう場合がある。例えば、図１２に例示するような木構造を作成する際、ルートのノードに行き着くまでの階層数が多ければ、その分だけ計算量が多くなる。このため、ブロックチェーンに記録する取引情報をゼロ知識証明により匿名化する場合、迅速なサービス提供が難しいという課題がある。この課題は、例えば、対面取引を行うサービスなどで特に問題となる。そこで、本開示は、匿名性を担保しつつ、迅速なサービス提供を実現できる情報処理装置、情報処理方法及び情報処理プログラムを提案する。
＜＜２．システム構成例＞＞
　以下、本開示の実施形態に係る情報処理システムの構成例を説明する。図１は、本開示の実施形態に係るシステム構成例を示す模式図である。図１に示すように、本開示の実施形態に係る情報処理システム１は、ユーザ端末１０と、サービス提供装置２０と、ＢＣクライアント装置３０と、ＢＣシステム４０と、データ利用者装置５０とを有する。情報処理システム１の構成は、図１に示す例には特に限定される必要はなく、図１に示すよりも多くのユーザ端末１０や、サービス提供装置２０や、ＢＣクライアント装置３０や、ＢＣシステム４０や、データ利用者装置５０を含んでいてもよい。
　ユーザ端末１０と、サービス提供装置２０と、ＢＣクライアント装置３０と、ＢＣシステム４０と、データ利用者装置５０とは、有線又は無線によりネットワークＮに接続される。ネットワークＮは、ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）、電話網（携帯電話網、固定電話網等）、地域ＩＰ（Internet　Protocol）網、インターネット等を含む。
　また、ユーザ端末１０及びサービス提供装置２０は、ネットワークＮを介して相互に通信できる。また、サービス提供装置２０及びＢＣクライアント装置３０は、ネットワークＮを介して相互に通信できる。また、サービス提供装置２０及びデータ利用者装置５０は、ネットワークＮを介して相互に通信できる。また、ＢＣクライアント装置３０及びＢＣシステム４０は、ネットワークＮを介して相互に通信できる。
　ユーザ端末１０は、例えば、個人情報をサービス提供装置２０に預けるユーザによって利用される情報処理装置である。ユーザ端末１０は、スマートフォン、タブレット型端末、ノート型ＰＣ（Personal　Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal　Digital　Assistant）等により実現され得る。
　サービス提供装置２０（情報管理装置の一例）は、ユーザ端末１０を用いて、ユーザ端末１０のユーザによりアップロードされた個人情報を管理する情報処理装置である。また、サービス提供装置２０は、例えば、個人情報のデータ要求元であるデータ利用者装置５０の利用者に対して、個人情報の閲覧権限を付与する。また、サービス提供装置２０は、個人情報のデータ要求元であるデータ利用者装置５０の利用者からゼロ知識証明のプルーフを受け付けて、受け付けたプルーフの検証結果に基づいて個人情報を提供する。サービス提供装置２０は、サーバ等により実現され得る。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、ＢＣシステム４０に対してデータの記録を行う情報処理装置である。ＢＣクライアント装置３０は、物理的又は機能的に後述するＢＣシステム４０に対して統合されていてもよい。また、ＢＣクライアント装置３０は、ＢＣシステム４０とは分散されていてもよい。ＢＣクライアント装置３０は、サーバ等により実現され得る。ＢＣクライアント装置３０の処理については後述する。
　ＢＣシステム４０は、個人情報の閲覧権限に関する情報や個人情報の要求に伴うプルーフの検証結果に関する情報などのデータを取りまとめた各ブロックを、処理順に連ねて構成したブロックチェーンとして管理する情報処理装置である。ＢＣシステム４０は、例えば、ブロックの生成やブロックチェーンの共有等の種々の処理を実行する複数の情報処理装置（ノード）により構成される。ＢＣシステム４０の各ノードは、例えば、ＮＩＣ（Network　Interface　Card）や通信回路等によって実現される通信部を備え、ネットワークＮと有線又は無線で接続される。ＢＣシステム４０は、サービス提供装置２０やデータ利用者装置５０が利用可能なパーミッション型のブロックチェーンを想定しているが、本開示の実施形態に係る処理を実現可能であれば、どのような構成であってもよい。
　データ利用者装置５０は、サービス提供装置２０に管理されている個人情報を取得するユーザによって利用される情報処理装置である。データ利用者装置５０は、スマートフォン、タブレット型端末、ノート型ＰＣ、デスクトップＰＣ、携帯電話機、ＰＤＡ等により実現され得る。データ利用者装置５０は、サービス提供装置２０から個人情報の閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを生成する。データ利用者装置５０は、生成したプルーフとともに、個人情報のデータ要求をサービス提供装置２０に送信することで、サービス提供装置２０から所望の個人情報を取得する。
＜＜３．情報処理の概要＞＞
＜３－１．情報処理例＞
　以下、本開示の実施形態に係る情報処理システムによる情報処理の一例について説明する。図２は、本開示の実施形態に係る情報処理の一例を示す模式図である。
　図２に示すように、ユーザ端末１０は、個人情報をサービス提供装置２０に送信する（ステップＳ１１）。サービス提供装置２０は、ユーザ端末１０から受信する個人情報をローカル環境で管理する（ステップ１２）。
　データ利用者装置５０は、サービス提供装置２０に対して、個人情報を閲覧するための閲覧権限の取得要求を送信する（ステップＳ１３）。サービス提供装置２０は、データ利用者装置５０から閲覧権限の取得要求を受信すると、閲覧権限の記録要求をＢＣクライアント装置３０に送信する（ステップＳ１４）。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、閲覧権限に関する情報をＢＣシステム４０に記録する（ステップＳ１５）。ここで、ＢＣクライアント装置３０がＢＣシステム４０に記録する閲覧権限に関する情報は、データ利用者装置５０のユーザによる個人情報の閲覧が許可されることを示す情報であり、任意の文字列等により構成できる。また、ＢＣクライアント装置３０は、閲覧権限に関する情報をそのままＢＣシステム４０に記録するのではなく、閲覧権限に関する情報をハッシュ化したハッシュ値をＢＣシステム４０に記録できる。
　サービス提供装置２０は、ＢＣクライアント装置３０による閲覧権限の記録後、閲覧権限をデータ利用者装置５０に付与する（ステップＳ１６）。サービス提供装置２０は、閲覧権限に関する情報とともに、閲覧権限をハッシュ化する際に組み込んだ秘密の値（乱数等）をデータ利用者装置５０に提供する。秘密の値は、ナンスであってもよい。
　データ利用者装置５０は、サービス提供装置２０から閲覧権限が付与されると、個人情報の閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを生成する（ステップＳ１７）。データ利用者装置５０が作成するプルーフとして、サービス提供装置２０からの要求に応じてＢＣクライアント装置３０がＢＣシステム４０に記録したハッシュ値と同じハッシュ値を作り出せることを示す証拠が想定される。例えば、データ利用者装置５０は、サービス提供装置２０から付与される秘密の値を用いて生成したハッシュ値そのものをプルーフとしてサービス提供装置２０に提示すればよい。そして、データ利用者装置５０は、生成したプルーフとともに、個人情報のデータ要求をサービス提供装置２０に送信する（ステップＳ１８）。
　サービス提供装置２０は、データ利用者装置５０からデータ要求を受信すると、プルーフの確認要求をＢＣクライアント装置３０に送信する（ステップＳ１９）。ＢＣクライアント装置３０は、サービス提供装置２０から受信するプルーフの確認要求に応じて、プルーフの検証を実行する（ステップＳ２０）。具体的には、ＢＣクライアント装置３０は、ＢＣシステム４０に記録した閲覧記録に関する情報のハッシュ値と、サービス提供装置２０から取得したプルーフに基づくハッシュ値を比較し、一致するか否かを判定する。
　ＢＣクライアント装置３０は、プルーフの検証結果を、利用履歴としてＢＣシステム４０に記録する（ステップＳ２１）。具体的には、ＢＣクライアント装置３０は、データ利用者装置５０から取得したプルーフが正当であったか否かを示すプルーフの検証結果に関する情報をＢＣシステム４０に記録する。このとき、ＢＣクライアント装置３０は、プルーフの検証時に、ＢＣシステム４０において記録された閲覧権限に関する情報のレコード位置と、データ利用者装置５０において生成されたプルーフとが紐付かないように、閲覧権限のレコード位置を除いて利用履歴の記録を行う。また、ＢＣクライアント装置３０は、プルーフの検証結果を、判定結果としてサービス提供装置２０に送信する（ステップＳ２２）。
　サービス提供装置２０は、ＢＣクライアント装置３０から受信するプルーフの判定結果に基づいて、データ利用者装置５０に対して、データ利用者装置５０から受信したデータ要求（ステップＳ１８参照）に対応する個人情報を提供する（ステップＳ２３）。
　上述してきたように、ＢＣクライアント装置３０は、予めＢＣシステム４０に記録された閲覧権限に関する情報（ハッシュ値）と、データ利用者装置５０において生成されたプルーフに基づくハッシュ値とを比較することにより、プルーフの検証を行う。「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を利用したゼロ知識証明では、ブロックチェーンに記録されたブロックデータからハッシュ値の計算に必要な全データを取得し、取得したデータを用いてルートとなるノードに至るまでハッシュ値を繰り返し計算する必要があるが、本開示の実施形態におけるゼロ知識証明では、ハッシュ値の計算はデータ利用者装置５０における１度だけでよく、生成したハッシュ値と記録されたハッシュ値との比較のみで済む。これにより、迅速なサービス提供（個人情報の提供）が可能となる。
　また、ＢＣクライアント装置３０は、検証結果をＢＣシステム４０に記録する際、プルーフの検証時に利用したＢＣシステム４０上の閲覧権限に関する情報（ハッシュ値）と、データ利用者装置５０において生成されたプルーフとを紐付ける情報を記録しないようにする。これにより、ＢＣシステム４０（ブロックチェーン）において、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」と同等の匿名性を実現できる。このようなことから、本開示の実施形態によれば、匿名性を担保しつつ、迅速なサービス提供を実現できる。
＜３－２．サービス例＞
　図３及び図４を用いて、本開示の実施形態に係る情報処理システムより実現されるサービス形態の一例を説明する。図３及び図４は、本開示の実施形態に係るサービス形態の概要を示す模式図である。
　図３は、医療サービスαが、自らが管理するユーザの生体情報や医療データなどをデータ利用者である医者や医療機関等に対して、提供するサービス形態を示している。図３に示すユーザは、図１や図２に示すユーザ端末１０のユーザに対応する。図３に示す医療サービスαは、図１や図２に示すサービス提供装置２０に対応する。図３に示すブロックチェーンは、図１や図２に示すＢＣクライアント装置３０やＢＣシステム４０に対応する。図３に示すデータ利用者は、図１や図２に示すデータ利用者装置５０のユーザに対応する。
　ユーザは、心電図や、心拍数や、血圧や、体温など所定の測定装置で測定可能な生体情報（バイタルサイン）や、医療機関における医療記録や健康診断結果などの医療データなどを医療サービスαにアップロードして予め登録する。
　医療サービスαは、ユーザからアップロードされた生体情報や医療データを個人情報として登録して管理する。医療サービスαは、生体情報や医療データを登録する際、医者や医療機関に対するデータ提供に同意するか否かを問い合わせる。医療サービスαは、データ提供に同意することを条件として、個人情報の登録を許可してもよい。医療サービスαは、データ利用者からの要求に応じて個人情報の閲覧権限に関する情報をブロックチェーンに記録し、閲覧権限をデータ利用者に付与する。
　データ利用者は、閲覧権限に基づくゼロ知識証明のプルーフを生成し、生成したプルーフとともにデータ要求を医療サービスαに送信する。
　医療サービスαは、データ利用者から受信したデータ要求に含まれるプルーフの検証結果に基づいて、データ要求に対応する個人情報を取得し、取得した個人情報をデータ利用者に提供する。また、医療サービスαは、ブロックチェーンに閲覧権限の利用履歴を記録する。
　図４は、データ共有サービスＸが、自らが管理する個人情報などをデータ利用者等に提供するサービス形態を示している。図４に示すユーザは、図１や図２に示すユーザ端末１０のユーザに対応する。図４に示すデータ共有サービスＸ，Ｙ，Ｚは、図１や図２に示すサービス提供装置２０に対応する。図４に示すブロックチェーンは、図１や図２に示すＢＣクライアント装置３０やＢＣシステム４０に対応する。図４に示すデータ利用者は、図１や図２に示すデータ利用者装置５０のユーザに対応する。なお、図４に示すデータ共有サービスＸ，Ｙ，Ｚは、同一の機能を有する。以下では、データ共有サービスＸを介して実行されるサービスの一例について説明する。
　ユーザは、年齢や、性別や、性別などの人口統計学的な属性の情報や、位置情報や、アプリケーションの利用履歴などのデータなどをデータ共有サービスＸにアップロードして予め登録する。
　データ共有サービスＸは、ユーザからアップロードされた個人情報を登録して管理する。データ共有サービスＸは、個人情報を登録する際、データ利用者に対するデータ提供に同意するか否かを問い合わせる。データ共有サービスＸは、データ提供に同意することを条件として、個人情報の登録を許可してもよい。データ共有サービスＸは、データ利用者からの要求に応じて個人情報の閲覧権限に関する情報をブロックチェーンに記録し、閲覧権限をデータ利用者に付与する。
　データ利用者は、閲覧権限に基づくゼロ知識証明のプルーフを生成し、生成したプルーフとともにデータ要求をデータ共有サービスＸに送信する。
　データ共有サービスＸは、データ利用者から受信したデータ要求に含まれるプルーフの検証結果に基づいて、データ要求に対応する個人情報を取得し、取得した個人情報をデータ利用者に提供する。また、データ共有サービスＸは、個人情報の利用履歴をブロックチェーンに記録する。また、データ共有サービスＸは、個人情報の利用に応じた報酬をユーザに付与する場合、報酬に関する情報をブロックチェーンに合わせて記録してもよい。
　このように、本開示の実施形態に係る情報処理システム１は、前述したような個人情報の提供に係る各種サービスに適用可能である。
＜＜４．装置構成例＞＞
　以下、本開示の実施形態に係るＢＣクライアント装置３０の構成について説明する。図５は、本開示の実施形態に係るＢＣクライアント装置の構成例を示すブロック図である。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、ブロックチェーンへのデータ記録等を実行する情報処理装置である。ＢＣクライアント装置３０は、ＢＣシステム４０を構成する情報処理装置の１つであってもよいし、ＢＣシステム４０から独立した情報処理装置であってもよい。
　図５に示すように、ＢＣクライアント装置３０は、通信部３１と、記憶部３２と、制御部３３とを有する。
　通信部３１は、ＮＩＣ（Network　Interface　Card）や各種通信用モデム等によって実現される。通信部３１は、ネットワークＮを介して、サービス提供装置２０と通信し、各種情報を送受信する。
　記憶部３２は、例えば、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部３２は、例えば、制御部３３により実行される各種処理機能を実現するためのプログラム及びデータ等を記憶できる。記憶部３２が記憶するプログラムには、制御部３３の各部に対応する処理機能を実現するためのプログラムが含まれる。記憶部３２が記憶するプログラムには、ＯＳ（Operating　System）や各種アプリケーションプログラムが含まれる。
　制御部３３は、第１記録部３３１と、検証部３３２と、第２記録部３３３と、送信部３３４とを有する。制御部３３が有する各機能部は、プロセッサやメモリを備えた制御回路により実現される。制御部３３が有する各機能部は、例えば、プロセッサによって内部メモリから読み込まれたプログラムに記述された命令が、内部メモリを作業領域として実行されることにより実現される。プロセッサが内部メモリから読み込むプログラムには、ＯＳ（Operating　System）やアプリケーションプログラムが含まれる。また、制御部３３が有する各機能部は、例えば、ＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field-Programmable　Gate　Array）等の集積回路により実現されてもよい。
　また、前述の内部メモリとして機能する主記憶装置や補助記憶装置は、例えば、ＲＡＭ（Random　Access　Memory)、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。
　第１記録部３３１は、データを管理するサービス提供装置２０からの要求に応じて、データの閲覧権限に関する情報をＢＣシステム４０に記録する。例えば、第１記録部３３１は、閲覧権限の記録要求をサービス提供装置２０から受信すると、記録要求に含まれるハッシュ値をＢＣシステム４０に書き込んで記録する。サービス提供装置２０が生成するハッシュ値は、「ＨＭＡＣ（Hash-based　Message　Authentication　Code）」を用いて、サービス提供装置２０が閲覧権限の要求元に付与する閲覧権限に関する情報と、サービス提供装置２０が閲覧権限の要求元との間で限定的に共有する秘密の値と、閲覧権限の要求元から提供される公開鍵とを用いて生成される。なお、ハッシュ値を生成する際に用いるハッシュ関数として、「ＨＭＡＣ（Hash-based　Message　Authentication　Code）」の他、「ＳＨＡ－２５６（Secure　Hash　Algorithm　256-bit）」や、「Ｐｅｄｅｒｓｅｎ　Ｃｏｍｍｉｔｍｅｎｔ」などの任意のハッシュ関数を用いることができる。
　検証部３３２は、ブロックチェーンに書き込まれた閲覧権限に関する情報に基づいて、閲覧権限を有する正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する。具体的には、検証部３３２は、サービス提供装置２０からプルーフの確認要求を受信すると、確認要求に含まれる閲覧権限の書き込み位置（レコード位置）に基づいて、ＢＣシステム４０から閲覧権限に関する情報の鍵付きハッシュ値を取得する。検証部３３２は、取得した鍵付きハッシュ値と、確認要求に含まれるプルーフに基づいて生成される鍵付きハッシュ値とを比較することにより、プルーフを検証する。検証部３３２は、ハッシュ値が同一であれば、閲覧権限を有する正当なユーザであると判定する。
　第２記録部３３３は、検証部３３２によるプルーフの検証結果に関する情報をＢＣシステム４０に記録する。第２記録部３３３は、プルーフの検証結果に関する情報をＢＣシステム４０に記録する際、プルーフと閲覧権限に関する情報とを紐付ける情報を記録しないようにする。例えば、第２記録部３３３は、プルーフの検証に関する情報のうち、プルーフの検証に用いられた閲覧権限に関する情報の書き込み位置（レコード位置）以外の情報をＢＣシステム４０に書き込む。
　送信部３３４は、データの要求元が閲覧権限を有する正当なユーザであるか否かの判定結果をサービス提供装置２０に送信する。
＜＜５．処理手順例＞＞
＜５－１．比較例に係る処理の流れ＞
　図６を用いて、比較例に係る処理手順として、ゼロ知識証明のプルーフとして「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を用いた場合の処理手順の一例を説明する。図６は、比較例に係る処理手順の一例を示すシーケンス図である。
　図６に示すように、ユーザ端末１０ＥＸは、サービス提供装置２０ＥＸに対して、個人情報を送信する（ステップＳ１０１）。サービス提供装置２０ＥＸは、個人情報の所有権があることをＢＣシステム４０ＥＸに書き込んで記録する（ステップＳ１０２）。
　また、データ利用者装置５０ＥＸは、個人情報の閲覧権限の取得要求をサービス提供装置２０ＥＸに送信する（ステップＳ１０３）。
　サービス提供装置２０ＥＸは、閲覧権限の取得要求の内容確認を行い（ステップＳ１０４）、ＢＣシステム４０ＥＸに対して、閲覧権限の記録を実行する（ステップＳ１０５）。そして、サービス提供装置２０ＥＸは、閲覧権限をデータ利用者装置５０ＥＸに付与する（ステップＳ１０６）。
　データ利用者装置５０ＥＸは、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」に使うレコードの要求をＢＣシステム４０ＥＸに送信する（ステップＳ１０７）。ＢＣシステム４０ＥＸは、データ利用者装置５０ＥＸからの要求に応じて、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」に使うレコードをデータ利用者装置５０ＥＸに渡す（ステップＳ１０８）。
　データ利用者装置５０ＥＸは、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を組み込んだ閲覧権限のゼロ知識証明を作成する（ステップＳ１０９）。そして、データ利用者装置５０ＥＸは、個人情報のデータ要求とともに、ゼロ知識証明のプルーフをサービス提供装置２０ＥＸに送信する（ステップＳ１１０）。
　サービス提供装置２０ＥＸは、ゼロ知識証明のプルーフを確認し（ステップＳ１１１）、利用履歴をＢＣシステム４０に書き込んで記録する（ステップＳ１１２）。そして、サービス提供装置２０ＥＸは、データ利用者装置５０ＥＸのユーザが正当な閲覧権限を有する場合、データ要求に対応する個人情報をデータ利用者装置５０ＥＸのユーザに提供する（ステップＳ１１３）。
＜５－２．本開示の実施形態に係る処理手順例＞
　図７を用いて、本開示の実施形態に係る処理手順例について説明する。図７は、本開示の実施形態に係る処理手順の一例を示すシーケンス図である。
　図７に示すように、ユーザ端末１０は、サービス提供装置２０に対して、個人情報を送信する（ステップＳ２０１）。サービス提供装置２０は、個人情報の所有権の記録要求をＢＣクライアント装置３０に送信する（ステップＳ２０２）。ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、個人情報の所有権があることをＢＣシステム４０に書き込んで記録する（ステップＳ２０３）。
　また、データ利用者装置５０は、個人情報の閲覧権限の取得要求をサービス提供装置２０に送信する（ステップＳ２０４）。なお、データ利用者装置５０は、公開鍵と秘密鍵の鍵ペアを予め作成し、サービス提供装置２０に対する閲覧権限の取得要求に際して、サービス提供装置２０に公開鍵を提供する。
　サービス提供装置２０は、閲覧権限の取得要求の内容確認を行い（ステップＳ２０５）、ＢＣクライアント装置３０に対して、閲覧権限の記録要求を送信する（ステップＳ２０６）。サービス提供装置２０は、閲覧権限に関する情報のハッシュ値を生成し、閲覧権限の記録要求に含めて送信する。このハッシュ値は、閲覧権限に関する情報と、閲覧権限の要求元であるデータ利用者装置５０との間で限定的に共有する秘密の値：「ｒ」と、閲覧権限の要求元であるデータ利用者装置５０から提供される公開鍵とを用いて生成される。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、閲覧権限に関する情報（ハッシュ値）をＢＣシステム４０に書き込んで記録する（ステップＳ２０７）。そして、ＢＣクライアント装置３０は、閲覧権限に関する情報の書き込み位置（レコード位置）をサービス提供装置２０に返信する（ステップＳ２０８）。
　サービス提供装置２０は、データ利用者装置５０に対して閲覧権限を付与する（ステップＳ２０９）。サービス提供装置２０は、閲覧権限として、秘密の値：「ｒ」と、ＢＣシステム４０における閲覧権限に関する情報のハッシュ値の書き込み位置（レコード位置）をデータ利用者装置５０に提供する。
　データ利用者装置５０は、閲覧権限のゼロ知識証明を作成する（ステップＳ２１０）。具体的には、データ利用者装置５０は、サービス提供装置２０に提供した公開鍵とペアの秘密鍵を公開鍵生成関数に入力して、公開鍵を生成する。データ利用者装置５０は、生成した公開鍵と、サービス提供装置２０から提供された秘密の値：「ｒ」と、閲覧権限に関する情報とに基づいて、ハッシュ関数からハッシュ値を生成するゼロ知識証明のプルーフを作成する。そして、データ利用者装置５０は、個人情報のデータ要求とともに、ゼロ知識証明のプルーフ及び閲覧権限の書き込み位置（レコード位置）をサービス提供装置２０に送信する（ステップＳ２１１）。
　サービス提供装置２０は、プルーフの確認要求をＢＣクライアント装置３０に送信する（ステップＳ２１２）。ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、データ利用者装置５０のプルーフを検証する（ステップＳ２１３）。具体的には、ＢＣクライアント装置３０は、データ利用者装置５０からサービス提供装置２０に送信されたデータ要求に含まれる閲覧情報書き込み位置（レコード位置）に記録されているハッシュ値をＢＣシステム４０から取得する。ＢＣクライアント装置３０は、ＢＣシステム４０から取得したハッシュ値と、データ利用者装置５０のプルーフに基づいて作成したハッシュ値とを比較することにより、データ利用者装置５０のプルーフを検証する。
　ＢＣクライアント装置３０は、プルーフの検証結果に関する情報を、利用履歴としてＢＣシステム４０に書き込んで記録する（ステップＳ２１４）。このとき、ＢＣクライアント装置３０は、プルーフの検証結果に関する情報のうち、プルーフの検証に用いられたＢＣシステム４０上のハッシュ値と、プルーフに基づいて生成されたハッシュ値とを紐付ける情報をＢＣシステム４０に記録しないようにする。そして、ＢＣクライアント装置３０は、データ利用者装置５０のユーザが正当な閲覧権限を有するか否かの判定結果をサービス提供装置２０に返信する（ステップＳ２１５）。
　サービス提供装置２０は、ＢＣクライアント装置３０から取得する判定結果に基づいて、データ利用者装置５０のユーザが正当な閲覧権限を有する場合、データ要求に対応する個人情報をデータ利用者装置５０に渡す（ステップＳ２１６）。
　上述した比較例に係る処理手順（図６参照）では、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を利用して、データ利用者装置５０ＥＸのユーザが正当な閲覧権限を有することをゼロ知識証明により証明するので、計算量が多くなり、個人情報の提供に至るまでの処理が遅くなる場合がある。例えば、前述のステップＳ１０７やステップＳ１０８におけるブロックチェーンに記録されたブロックデータの取得や、前述のステップ１０９におけるプルーフの作成、前述のステップＳ１１１における木構造の作成に時間を要する場合がある。
　一方、本開示の実施形態に係る処理手順（図７参照）において、ＢＣクライアント装置３０は、データ利用者装置５０のユーザが正当な閲覧権限を有することを証明するためのゼロ知識証明のプルーフを検証する。このプルーフには、サービス提供装置２０とデータ利用者装置５０との間で限定的に共有される秘密の値：「ｒ」を用いて生成されたハッシュ値が組み込まれる。これにより、ＢＣクライアント装置３０は、プルーフを検証する際、ブロックチェーンからプルーフの検証に必要となるブロックデータの取得に要する時間や、ルートとなるノードに至るまで繰り返し実行するハッシュ値の計算に要する時間等が不要となり、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」を利用するよりも処理を高速化できる。また、本開示の実施形態に係る処理手順（図７参照）において、ＢＣクライアント装置３０は、プルーフの検証結果に関する情報をブロックチェーンに記録する際、プルーフと閲覧権限に関する情報とを紐付ける情報を記録しない。これにより、ブロックチェーン上において、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」と同等の匿名性を実現できる。なお、サービス提供装置２０とＢＣシステム４０との間にＢＣクライアント装置３０を配置することにより、ＢＣシステム４０が運営するブロックチェーンへの新規参入があった場合であっても、情報処理システム１の可用性を高めることができる。すなわち、サービス提供装置２０が直接ブロックチェーンに参加した場合、分散型台帳の機能を果たすために他の参加者とのやり取りが必要となる。これに対し、本開示の実施形態のように、ＢＣクライアント装置３０を介してブロックチェーンとのやり取りを行うようにしておくことにより、仮にサービス提供装置２０がダウンしたとしても、ＢＣクライアント装置３０がサービス提供装置２０との依存関係を切り離すことにより、他のブロックチェーン参加者はサービスの提供を継続できる。
＜＜６．変形例＞＞
＜６－１．閲覧権限の更新＞
　上記実施形態において、第２記録部３３３は、検証部３３２によるプルーフの検証が行われるたびに、閲覧権限に関する情報を更新して、ＢＣシステム４０に記録するようにしてもよい。このように、データ利用者装置５０において生成され、ゼロ知識証明に利用されたプルーフの利用回数を１度だけに限定することにより、データの傍受によるプルーフの再利用を未然に防ぐことができる。以下、図８を用いて、閲覧権限の更新に関する処理の流れを説明する。図８は、本開示の変形例に係る処理手順の一例を示すシーケンス図である。図８に示す処理のうち、ステップＳ３１０と、ステップＳ３１１と、ステップＳ３１４と、ステップＳ３１６の処理が、図７に示す処理とは異なる。
　図８に示すように、ユーザ端末１０は、サービス提供装置２０に対して、個人情報を送信する（ステップＳ３０１）。サービス提供装置２０は、個人情報の所有権の記録要求をＢＣクライアント装置３０に送信する（ステップＳ３０２）。ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、個人情報の所有権があることをＢＣシステム４０に書き込んで記録する（ステップＳ３０３）。
　また、データ利用者装置５０は、個人情報の閲覧権限の取得要求をサービス提供装置２０に送信する（ステップＳ３０４）。サービス提供装置２０は、閲覧権限の取得要求の内容確認を行い（ステップＳ３０５）、ＢＣクライアント装置３０に対して、閲覧権限の記録要求を送信する（ステップＳ３０６）。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、閲覧権限に関する情報（ハッシュ値）をＢＣシステム４０に書き込んで記録する（ステップＳ３０７）。そして、ＢＣクライアント装置３０は、閲覧権限に関する情報の書き込み位置（レコード位置）をサービス提供装置２０に返信する（ステップＳ３０８）。サービス提供装置２０は、データ利用者装置５０に対して閲覧権限を付与する（ステップＳ３０９）。
　データ利用者装置５０は、閲覧権限のゼロ知識証明を作成するとともに、新しい秘密の値及び新しい秘密の値に基づく新しいハッシュ値を作成する（ステップＳ３１０）。そして、データ利用者装置５０は、個人情報のデータ要求とともに、ゼロ知識証明のプルーフと閲覧権限の書き込み位置（レコード位置）と新しいハッシュ値とをサービス提供装置２０に送信する（ステップＳ３１１）。新しい秘密の値ではなく、新しい秘密の値に基づくハッシュ値を送信することにより、中間者攻撃に対する安全性を担保できる。
　サービス提供装置２０は、プルーフの確認要求をＢＣクライアント装置３０に送信する（ステップＳ３１２）。また、サービス提供装置２０は、プルーフの確認要求とともに、データ利用者装置５０から受信した新しいハッシュ値をＢＣクライアント装置３０に送る。
　ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、データ利用者装置５０のプルーフを検証する（ステップＳ３１３）。また、ＢＣクライアント装置３０は、プルーフの検証結果に関する情報を、利用履歴としてＢＣシステム４０に書き込んで記録するとともに、サービス提供装置２０から受信した新しいハッシュ値により閲覧権限を更新する（ステップＳ３１４）。これにより、次回のデータ利用時において、古いプルーフを用いたデータ要求は受け入れられなくなる。
　そして、ＢＣクライアント装置３０は、データ利用者装置５０のユーザが正当な閲覧権限を有するか否かの判定結果をサービス提供装置２０に返信する（ステップＳ３１５）。このとき、ＢＣクライアント装置３０は、更新した閲覧権限に関する情報（新しいハッシュ値）の書き込み位置（レコード位置）をサービス提供装置２０に送る。
　サービス提供装置２０は、ＢＣクライアント装置３０から取得する判定結果に基づいて、データ利用者装置５０のユーザが正当な閲覧権限を有する場合、データ要求に対応する個人情報とともに、更新した閲覧権限に関する情報の書き込み位置（レコード位置）をデータ利用者装置５０に渡す（ステップＳ３１６）。
　なお、データ利用者装置５０がデータを再度取得する場合には、ステップＳ３１１でサービス提供装置２０に送信した新しいハッシュ値の元となるステップＳ３１０で作成した新しい秘密の値を使う。ＢＣクライアント装置３０は、常に最新のハッシュ値を使うようにし、古いハッシュ値に基づくプルーフはリジェクトする。
＜６－２．閲覧権限の無効化＞
　上記実施形態において、ＢＣクライアント装置３０は、閲覧権限の取消対象を列挙したリボケーションリストをＢＣシステム４０に記録してもよい。図９は、本開示の変形例に係るＢＣクライアント装置の構成例を示すブロック図である。変形例に係るＢＣクライアント装置３０は、更新部３３５を有する点が上記実施形態と相違する。
　更新部３３５は、サービス提供装置２０からの要求に応じて、ＢＣシステム４０に記録されたリボケーションリストを更新する。検証部３３２は、プルーフの検証に先立って、プルーフの証明者がリボケーションリストに含まれるか否かを検証する。
　以下、図１０を用いて、閲覧権限の無効化に関する処理の流れを説明する。図１０は、本開示の変形例に係る処理手順の一例を示すシーケンス図である。なお、図１０は、データ利用者装置５０のユーザが閲覧権限の取消対象（リボーク対象）である場合の処理の流れの一例を示している。
　図１０に示すように、ユーザ端末１０は、リボーク要求をサービス提供装置２０に送信する（ステップＳ４０１）。サービス提供装置２０は、リボーク要求をＢＣクライアント装置３０に転送する（ステップＳ４０２）。
　ＢＣクライアント装置３０は、サービス提供装置２０から受信したリボーク要求に応じて、ＢＣシステム４０に記録されているリボケーションリストを更新する（ステップＳ４０３）。
　データ利用者装置５０は、個人情報のデータ要求とともに、ゼロ知識証明のプルーフと閲覧権限の書き込み位置（レコード位置）と新しい秘密の値とをサービス提供装置２０に送信する（ステップＳ４０４）。
　サービス提供装置２０は、プルーフの確認要求をＢＣクライアント装置３０に送信する（ステップＳ４０５）。
　ＢＣクライアント装置３０は、サービス提供装置２０からプルーフの確認要求を受信すると、リボケーションリストの確認及びプルーフの検証を実行する（ステップＳ４０６）。ＢＣクライアント装置３０は、データ利用者装置５０のユーザがリボケーションリストのリボーク対象に該当する場合、プルーフの検証を実行しない。具体的には、ＢＣクライアント装置３０は、ＢＣシステム４０に記録されたリボケーションリストを参照し、プルーフの証明者（データ利用者装置５０のユーザ）がリボーク対象となっているか否かを確認する。そして、ＢＣクライアント装置３０は、プルーフの証明者がリボーク対象である場合、プルーフの検証を実行せずに、判定結果としてリジェクト（リボーク対象である旨）をサービス提供装置２０に返信する（ステップＳ４０７）。なお、ＢＣクライアント装置３０は、プルーフの証明者がリボケーションリストのリボーク対象に該当しない場合、上記実施形態と同様にして、プルーフの検証を実行する。
　サービス提供装置２０は、ＢＣクライアント装置３０から受信した検証結果に基づいて、リジェクトされたことをデータ利用者装置５０のユーザに通知する（ステップＳ４０８）。
＜＜７．その他＞＞
　本開示の実施形態及び変形例に係るＢＣクライアント装置３０は、専用のコンピュータシステムで実現してもよいし、汎用のコンピュータシステムで実現してもよい。
　また、本開示の実施形態及び変形例に係るＢＣクライアント装置３０により実行される情報処理方法を実現するための各種プログラムを、光ディスク、半導体メモリ、磁気テープ、フレキシブルディスク等のコンピュータ読み取り可能な記録媒体等に格納して配布してもよい。このとき、本開示の実施形態及び変形例に係るＢＣクライアント装置３０は、各種プログラムをコンピュータにインストールして実行することにより、本開示の実施形態及び変形例に係る情報処理方法を実現できる。
　また、本開示の実施形態及び変形例に係るＢＣクライアント装置３０により実行される報処理方法を実現するための各種プログラムを、インターネット等のネットワーク上のサーバが備えるディスク装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。また、本開示の実施形態及び変形例に係るＢＣクライアント装置３０により実行される情報処理方法を実現するための各種プログラムにより提供される機能を、ＯＳとアプリケーションプログラムとの協働により実現してもよい。この場合には、ＯＳ以外の部分を媒体に格納して配布してもよいし、ＯＳ以外の部分をアプリケーションサーバに格納しておき、コンピュータにダウンロード等できるようにしてもよい。
　また、本開示の実施形態及び変形例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
　また、本開示の実施形態に係る及び変形例に係るＢＣクライアント装置３０の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、ＢＣクライアント装置３０の制御部３３が有する検証部３３２と第２記録部３３３とを機能的に統合して構成してもよい。
　また、本開示の実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、本開示の実施形態に係るフローチャートに示された各ステップは、適宜順序を変更することが可能である。
　以上、本開示の実施形態及び変形例について説明したが、本開示の技術的範囲は、上述の実施形態及び変形例に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、異なる実施形態及び変形例にわたる構成要素を適宜組み合わせてもよい。
＜＜８．ハードウェア構成例＞＞
　図１１を用いて、本開示の実施形態及び変形例に係るＢＣクライアント装置３０を実現可能なコンピュータのハードウェア構成例について説明する。図１１は、本開示の実施形態及び変形例に係るＢＣクライアント装置を実現可能なコンピュータのハードウェア構成例を示すブロック図である。なお、図１１は、コンピュータの一例を示すものであり、図１１に示す構成には限定される必要はない。
　図１１に示すように、本開示の実施形態及び変形例に係るＢＣクライアント装置３０は、例えば、プロセッサ１００１と、メモリ１００２と、通信モジュール１００３とを有するコンピュータ１０００により実現できる。
　プロセッサ１００１は、典型的には、ＣＰＵ（Central　Processing　Unit）や、ＤＳＰ（Digital　Signal　Processor）や、ＳｏＣ（System-on-a-Chip）や、システムＬＳＩ（Large　Scale　Integration）などである。
　メモリ１００２は、典型的には、ＲＡＭ（Random　Access　Memory）や、ＲＯＭ（Read　Only　Memory）や、フラッシュメモリ等の不揮発性または揮発性の半導体メモリ、又は磁気ディスクなどである。ＢＣクライアント装置３０が有する記憶部３２は、メモリ１００２により実現される。
　通信モジュール１００３は、典型的には、有線又は無線ＬＡＮ（Local　Area　Network）や、ＬＴＥ（Long　Term　Evolution）や、Ｂｌｕｅｔｏｏｔｈ（登録商標）や、ＷＵＳＢ（Wireless　USB）用の通信カードや、光通信用のルータや、各種通信用モデムなどである。上記実施形態に係るＢＣクライアント装置３０が通信部３１の機能は、通信モジュール１００３により実現される。
　プロセッサ１００１は、例えば、演算処理装置又は制御装置として機能し、メモリ１００２に記録された各種プログラムに基づいて、各構成要素の動作全般又はその一部を制御する。ＢＣクライアント装置３０が有する各機能部（第１記録部３３１、検証部３３２、第２記録部３３３、送信部３３４、及び更新部３３５）は、プロセッサ１００１が、各機能部として動作するための命令が記述された情報処理プログラムをメモリ１００２から読み込んで実行することにより実現される。
　すなわち、プロセッサ１００１及びメモリ１００２は、ソフトウェア（メモリ１００２に記憶される情報処理プログラム）との協働により、ＢＣクライアント装置３０が有する各機能部による情報処理を実現する。
＜＜９．むすび＞＞
　本開示の実施形態に係るＢＣクライアント装置３０（情報処理装置の一例）は、第１記録部３３１と、検証部３３２と、第２記録部３３３とを有する。第１記録部３３１は、データを管理するサービス提供装置２０（情報管理装置の一例）からの要求に応じて、データ（例えば、個人情報）の閲覧権限に関する情報をＢＣシステム４０（ブロックチェーンの一例）に記録する。検証部３３２は、ＢＣシステム４０に書き込まれた閲覧権限に関する情報に基づいて、閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する。第２記録部３３３は、プルーフの検証結果に関する情報をＢＣシステム４０に記録する。このようなことから、ＢＣクライアント装置３０は、匿名性を担保しつつ、迅速なサービス提供を実現できる。
　また、第１記録部３３１は、データを要求するデータ要求者（例えば、データ利用者装置５０のユーザ）とサービス提供装置２０との間で共有される秘密の情報（例えば、秘密の情報：「ｒ」）を用いて、閲覧権限に関する情報（例えば、任意の文字列）をハッシュ化したハッシュ値（例えば、鍵付きハッシュ値）をＢＣシステム４０に記録する。これにより、ブロックチェーン上に個人情報を直接記録することなく、利用履歴の追跡が可能となる。
　また、第２記録部３３３は、プルーフの検証結果に関する情報をブロックチェーンに記録する際、プルーフと閲覧権限に関する情報とを紐付ける情報を記録しない。これにより、ＢＣシステム４０（ブロックチェーン）において、「Ｍｅｒｋｌｅ　Ｔｒｅｅ」と同等の匿名性を実現できる。
　また、第２記録部３３３は、検証部３３２による検証が行われるたびに、閲覧権限に関する情報を更新して、ＢＣシステム４０に記録する。これにより、データの傍受によるプルーフの再利用を未然に防ぐことができる。
　また、ＢＣクライアント装置３０は、サービス提供装置２０からの要求に応じて、ＢＣシステム４０に記録されたリボケーションリストを更新する更新部３３５をさらに備える。また、検証部３３２は、プルーフの検証に先立って、プルーフの証明者がリボケーションリストに含まれるか否かを検証する。これにより、ユーザが個人情報の開示を希望しないデータ利用者のプルーフの検証を回避できる。
　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示の技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者にとって明らかな他の効果を奏しうる。
　なお、本開示の技術は、本開示の技術的範囲に属するものとして、以下のような構成もとることができる。
（１）
　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録する第１記録部と、
　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する検証部と、
　前記プルーフの検証結果に関する情報を前記ブロックチェーンに記録する第２記録部と
　を有する情報処理装置。
（２）
　前記第１記録部は、
　前記データを要求するデータ要求者と前記情報管理装置との間で共有される秘密の情報を用いて、前記閲覧権限に関する情報をハッシュ化したハッシュ値を前記ブロックチェーンに記録する
　前記（１）に記載の情報処理装置。
（３）
　前記第２記録部は、
　前記プルーフの検証結果に関する情報をブロックチェーンに記録する際、前記プルーフと前記閲覧権限に関する情報とを紐付ける情報を記録しない
　前記（１）又は（２）に記載の情報処理装置。
（４）
　前記第２記録部は、
　前記検証部による検証が行われるたびに、前記閲覧権限に関する情報を更新して、前記ブロックチェーンに記録する
　前記（１）～前記（３）のいずれか１つに記載の情報処理装置。
（５）
　前記情報管理装置からの要求に応じて、前記ブロックチェーンに記録されたリボケーションリストを更新する更新部
　をさらに備え、
　前記検証部は、
　前記プルーフの検証に先立って、前記プルーフの証明者が前記リボケーションリストに含まれるか否かを検証する
　前記（１）に記載の情報処理装置。
（６）
　プロセッサが、
　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録し、
　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証し、
　前記閲覧権限の検証結果に関する情報を前記ブロックチェーンに記録する
　情報処理方法。
（７）
　プロセッサに、
　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録させ、
　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証させ、
　前記閲覧権限の検証結果に関する情報を前記ブロックチェーンに記録させる
　情報処理プログラム。
１　情報処理システム
１０　ユーザ端末
２０　サービス提供装置
３０　ＢＣクライアント装置
３１　通信部
３２　記憶部
３３　制御部
４０　ＢＣシステム
５０　データ利用者装置
３３１　第１記録部
３３２　検証部
３３３　第２記録部
３３４　送信部
３３５　更新部

Claims (7)

  1. 　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録する第１記録部と、
    　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証する検証部と、
    　前記プルーフの検証結果に関する情報を前記ブロックチェーンに記録する第２記録部と
    　を有する情報処理装置。
  2. 　前記第１記録部は、
    　前記データを要求するデータ要求者と前記情報管理装置との間で共有される秘密の情報を用いて、前記閲覧権限に関する情報をハッシュ化したハッシュ値を前記ブロックチェーンに記録する
    　請求項１に記載の情報処理装置。
  3. 　前記第２記録部は、
    　前記プルーフの検証結果に関する情報をブロックチェーンに記録する際、前記プルーフと前記閲覧権限に関する情報とを紐付ける情報を記録しない
    　請求項２に記載の情報処理装置。
  4. 　前記第２記録部は、
    　前記検証部による検証が行われるたびに、前記閲覧権限に関する情報を更新して、前記ブロックチェーンに記録する
    　請求項３に記載の情報処理装置。
  5. 　前記情報管理装置からの要求に応じて、前記ブロックチェーンに記録されたリボケーションリストを更新する更新部
    　をさらに備え、
    　前記検証部は、
    　前記プルーフの検証に先立って、前記プルーフの証明者が前記リボケーションリストに含まれるか否かを検証する
    　請求項１に記載の情報処理装置。
  6. 　プロセッサが、
    　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録し、
    　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証し、
    　前記プルーフの検証結果に関する情報を前記ブロックチェーンに記録する
    　情報処理方法。
  7. 　プロセッサに、
    　データを管理する情報管理装置からの要求に応じて、前記データの閲覧権限に関する情報をブロックチェーンに記録させ、
    　前記ブロックチェーンに書き込まれた前記閲覧権限に関する情報に基づいて、前記閲覧権限を付与された正当なユーザであることを証明するためのゼロ知識証明のプルーフを検証させ、
    　前記プルーフの検証結果に関する情報を前記ブロックチェーンに記録させる
    　情報処理プログラム。
PCT/JP2021/039765 2020-11-10 2021-10-28 情報処理装置、情報処理方法及び情報処理プログラム WO2022102418A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022561813A JPWO2022102418A1 (ja) 2020-11-10 2021-10-28
US18/251,541 US20240015021A1 (en) 2020-11-10 2021-10-28 Information processing device, information processing method, and information processing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020186955 2020-11-10
JP2020-186955 2020-11-10

Publications (1)

Publication Number Publication Date
WO2022102418A1 true WO2022102418A1 (ja) 2022-05-19

Family

ID=81601090

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/039765 WO2022102418A1 (ja) 2020-11-10 2021-10-28 情報処理装置、情報処理方法及び情報処理プログラム

Country Status (3)

Country Link
US (1) US20240015021A1 (ja)
JP (1) JPWO2022102418A1 (ja)
WO (1) WO2022102418A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020010267A (ja) * 2018-07-12 2020-01-16 コニカミノルタ株式会社 分散型医療情報共有システム、医療情報提供サーバー及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020010267A (ja) * 2018-07-12 2020-01-16 コニカミノルタ株式会社 分散型医療情報共有システム、医療情報提供サーバー及びプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Virtual Currency Textbook: How cryptocurrencies such as Bitcoin work", 9 December 2016, NIKKEI BUSINESS PUBLICATIONS, INC., JP, ISBN: 978-4-8222-8545-6, article NARAYANAN, A. ET AL.: "Section 6.5", pages: 276 - 288, XP009536767 *
KEN NAGANUMA; MASAYUKI YOSHINO; HISAYOSHI SATO; TAKAYUKI SUZUKI: "Auditable Zerocoin", SUMMARY OF 2017 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY (SCIS 2017), JANUARY 24-27, 2017, IEICE, JP, 24 January 2017 (2017-01-24) - 27 January 2017 (2017-01-27), JP, pages 1 - 5, XP009536964 *

Also Published As

Publication number Publication date
US20240015021A1 (en) 2024-01-11
JPWO2022102418A1 (ja) 2022-05-19

Similar Documents

Publication Publication Date Title
US11533164B2 (en) System and method for blockchain-based cross-entity authentication
US10728042B2 (en) System and method for blockchain-based cross-entity authentication
EP3788523B1 (en) System and method for blockchain-based cross-entity authentication
JP7177575B2 (ja) ランダム・シーケンスを生成および検証するための分散型台帳
US10915552B2 (en) Delegating credentials with a blockchain member service
WO2021000419A1 (en) System and method for blockchain-based cross-entity authentication
US10735202B2 (en) Anonymous consent and data sharing on a blockchain
US20210304200A1 (en) Method, apparatus, and computer-readable medium for secured multi-lateral data exchange over a computer network
AU2017100968A4 (en) System for issuance, verification and use of digital identities on a public or private ledger.
US20200052880A1 (en) Ad-hoc trusted groups on a blockchain
Huang et al. MedBloc: A blockchain-based secure EHR system for sharing and accessing medical data
US11856107B2 (en) Methods and systems for exchanging confidential information via a blockchain
JP2024507908A (ja) Ｓｓｉを用いたブロックチェーンネットワークアイデンティティ管理
Liang et al. Towards blockchain empowered trusted and accountable data sharing and collaboration in mobile healthcare applications
US20230421543A1 (en) Method, apparatus, and computer-readable medium for secured data transfer over a decentrlaized computer network
WO2022102418A1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP2023098847A (ja) 装置、方法、コンピュータプログラム（プライバシー保護ブロックチェーンの選択的監査プロセス）
JP2023087665A (ja) システム、方法、およびコンピュータプログラム製品（許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャル）
US20240161889A1 (en) Systems and methods for providing access to electronic health records using a virtual health wallet
US20240187259A1 (en) Method and apparatus for generating, providing and distributing a trusted electronic record or certificate based on an electronic document relating to a user
US20230099538A1 (en) Private ledger partitions in blockchain networks
CN115776381A (zh) 基于区块链系统的密钥处理方法、装置、介质及电子设备
Klingelbrunner Datenschutz in SSI Systemen basierend auf Hyperledger Technologie
Zhuang et al. Self-Sovereign Identity Empowered Non-Fungible Patient Tokenization for Patient-Centric Health Information Exchange Using Blockchain Technology

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: 21891665

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022561813

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18251541

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21891665

Country of ref document: EP

Kind code of ref document: A1