WO2018105038A1 - 通信装置及び分散型元帳システム - Google Patents

通信装置及び分散型元帳システム Download PDF

Info

Publication number
WO2018105038A1
WO2018105038A1 PCT/JP2016/086244 JP2016086244W WO2018105038A1 WO 2018105038 A1 WO2018105038 A1 WO 2018105038A1 JP 2016086244 W JP2016086244 W JP 2016086244W WO 2018105038 A1 WO2018105038 A1 WO 2018105038A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
signature
unit
key
user
Prior art date
Application number
PCT/JP2016/086244
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 PCT/JP2016/086244 priority Critical patent/WO2018105038A1/ja
Publication of WO2018105038A1 publication Critical patent/WO2018105038A1/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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the present invention relates to a distributed ledger system that facilitates multi-person transactions and a communication device in the distributed ledger system.
  • Blockchain is a technology that forms the core of Bitcoin (registered trademark), which is a cryptocurrency, and was proposed in Non-Patent Document 1.
  • a block in which a plurality of transaction records between users using an electronic signature are collected is chained by a hash function.
  • the block chain prevents falsification of the ledger, which is a set of continuous transaction records, and enables the ledger to be distributed and managed among a plurality of users who cannot trust each other.
  • Each transaction in the blockchain is composed of four elements: the original transaction, the transaction content, the electronic signature of the transmission source user, and the public key of the transmission destination user.
  • the validity of each transaction can be confirmed by verifying the electronic signature of the transmission source user with the public key of the transmission destination user in the original transaction.
  • the content exchanged in each transaction can be used for the next transaction only for users who have a secret key corresponding to the public key of the destination user, and who can perform transactions correctly. It becomes possible to control.
  • the content of each transaction is the transfer of cryptocurrency in units of BTC from user to user.
  • the transmission source user designates the quantity of BTC to be transferred as the transaction content with the transaction in which the transmission source user's public key is set as the transmission destination user's public key, and uses the transmission source user's private key Generate a digital signature and create a transaction that pays the BTC by specifying the public key of the destination user.
  • the block chain in Bitcoin (registered trademark) has a problem that it is not suitable for transactions between groups of multiple users because the private key and public key of the electronic signature are linked as a single pair.
  • This invention is intended to make it possible to control the authority for each user when a transaction using a block chain is performed between groups of a plurality of users.
  • the communication device is: Transaction information including contents to be traded using a master secret key that is a pair of public keys in the group to which the user belongs and a user secret key generated based on a policy that restricts the signature target, and the public key of the destination group
  • a signature generation unit for generating a signature for A transaction output unit configured to output a transaction including the signature generated by the signature generation unit and the transaction information;
  • a signature is generated using a user private key generated based on a policy that restricts a signature target.
  • the authority for every user is controllable when performing the transaction by a block chain between the group which consists of a some user.
  • FIG. 1 is a configuration diagram of a distributed ledger system 1 according to Embodiment 1.
  • FIG. 1 is a configuration diagram of a key generation device 10 according to Embodiment 1.
  • FIG. 3 is a configuration diagram of a master key generation unit 21 according to Embodiment 1.
  • FIG. FIG. 3 is a configuration diagram of a user key generation unit 22 according to the first embodiment.
  • 1 is a configuration diagram of a communication device 30 according to Embodiment 1.
  • FIG. The block diagram of the transaction generation part 41 which concerns on Embodiment 1.
  • FIG. The block diagram of the transaction verification part 42 which concerns on Embodiment 1.
  • FIG. FIG. 3 is a configuration diagram of a block generation unit 43 according to the first embodiment.
  • FIG. 3 is a configuration diagram of a block verification unit 44 according to the first embodiment.
  • FIG. 4 is a flowchart of master key generation processing according to the first embodiment.
  • 5 is a flowchart of user key generation processing according to the first embodiment.
  • 5 is a flowchart of transaction generation processing according to the first embodiment.
  • FIG. 5 is a flowchart of transaction verification processing according to the first embodiment. The figure which shows the flow of the transaction tx which concerns on Embodiment 1.
  • FIG. 5 is a flowchart of block generation processing according to the first embodiment.
  • 5 is a flowchart of block verification processing according to the first embodiment.
  • FIG. The block diagram of the distributed ledger system 1 which concerns on the modification 1.
  • FIG. 1 The block diagram of the key generation apparatus 10 which concerns on the modification 3.
  • FIG. The block diagram of the communication apparatus 30 which concerns on the modification 3.
  • FIG. Explanatory drawing of transaction tx which concerns on Embodiment 2.
  • Embodiment 1 FIG. *** Explanation of configuration *** A configuration of a distributed ledger system 1 according to the first embodiment will be described with reference to FIG.
  • the distributed ledger system 1 includes a key generation device 10 and one or more communication devices 30 belonging to each of a plurality of groups. Each group has one or more users.
  • the communication devices 30 of each group are connected via a network 50 and can communicate with each other.
  • the key generation device 10 and the communication device 30 belonging to each group are connected via a transmission path and can communicate with each other.
  • the key generation device 10 is a computer such as a personal computer and a workstation.
  • the key generation device 10 includes hardware including a processor 11, a memory 12, a storage 13, and a communication interface 14.
  • the processor 11 is connected to other hardware via a signal line, and controls these other hardware.
  • the key generation device 10 includes a master key generation unit 21 and a user key generation unit 22 as functional components.
  • the functions of the master key generation unit 21 and the user key generation unit 22 are realized by software.
  • the storage 13 stores programs that realize the functions of the master key generation unit 21 and the user key generation unit 22. This program is read into the memory 12 by the processor 11 and executed by the processor 11. Thereby, the functions of the master key generation unit 21 and the user key generation unit 22 are realized. In addition, the storage 13 realizes the functions of the master key storage unit 131 and the user key storage unit 132.
  • the master key generation unit 21 includes a security parameter reception unit 211, a key generation unit 212, and a key output unit 213.
  • the user key generation unit 22 includes a master key acquisition unit 221, a policy reception unit 222, a key generation unit 223, and a key output unit 224.
  • the communication device 30 is a computer such as a personal computer, a workstation, a smartphone, and a tablet terminal.
  • the communication device 30 includes hardware of a processor 31, a memory 32, a storage 33, and a communication interface 34.
  • the processor 31 is connected to other hardware via a signal line, and controls these other hardware.
  • the communication device 30 includes a transaction generation unit 41, a transaction verification unit 42, a block generation unit 43, and a block verification unit 44 as functional components.
  • the functions of the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44 are realized by software.
  • the storage 33 stores programs for realizing the functions of the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44.
  • This program is read into the memory 32 by the processor 31 and executed by the processor 31.
  • the function of the transaction generation part 41, the transaction verification part 42, the block generation part 43, and the block verification part 44 is implement
  • the storage 33 realizes the functions of the transaction storage unit 331 and the block storage unit 332.
  • the transaction generation unit 41 includes a user key acquisition unit 411, a content reception unit 412, a signature generation unit 413, and a transaction output unit 414.
  • the transaction verification unit 42 includes a transaction acquisition unit 421, a content verification unit 422, a signature verification unit 423, and a result output unit 424.
  • the block generation unit 43 includes a transaction collection unit 431, a block generation unit 432, and a block output unit 433.
  • the block verification unit 44 includes a block acquisition unit 441, a block verification unit 442, and a result output unit 443.
  • the processors 11 and 31 are ICs (Integrated Circuits) that perform processing.
  • the processors 11 and 31 are a CPU (Central Processing Unit), a DSP (Digital Signal Processor), and a GPU (Graphics Processing Unit).
  • the memories 12 and 32 are storage devices for temporarily storing data. Specific examples of the memories 12 and 32 are SRAM (Static Random Access Memory) and DRAM (Dynamic Random Access Memory).
  • the storages 13 and 33 are storage devices for storing data.
  • the storage 13 is, as a specific example, an HDD (Hard Disk Drive).
  • the storages 13 and 33 may be SD (registered trademark, Secure Digital) memory card, CF (CompactFlash), NAND flash, flexible disk, optical disk, compact disk, Blu-ray (registered trademark) disk, DVD (Digital Versatile Disk), etc. It may be a portable storage medium.
  • the communication interfaces 14 and 34 are interfaces for communicating with external devices.
  • the communication interfaces 14 and 34 are Ethernet (registered trademark), USB (Universal Serial Bus), and HDMI (registered trademark, High-Definition Multimedia Interface) ports.
  • the key generation device 10 may include a plurality of processors that replace the processor 11.
  • the communication device 30 may include a plurality of processors that replace the processor 31.
  • the plurality of processors share the execution of a program that realizes the function of each functional component.
  • Each processor is an IC that performs processing in the same manner as the processors 11 and 31.
  • the operation of the distributed ledger system 1 according to the first embodiment will be described with reference to FIGS.
  • the operation of the key generation apparatus 10 in the distributed ledger system 1 according to the first embodiment corresponds to the key generation method according to the first embodiment.
  • the operation of the key generation apparatus 10 in the distributed ledger system 1 according to the first embodiment corresponds to the processing of the key generation program according to the first embodiment.
  • the operation of the communication device 30 in the distributed ledger system 1 according to the first embodiment corresponds to the communication method according to the first embodiment.
  • the operation of the communication device 30 in the distributed ledger system 1 according to the first embodiment corresponds to the processing of the communication program according to the first embodiment.
  • a policy-based signature is used as a signature method.
  • a policy ⁇ that restricts the signature target is set for the user private key sk ⁇ , and it is possible to generate a correct signature only for the data that is to be signed by the policy ⁇ .
  • a master key generation process that is an operation of the master key generation unit 21 according to the first embodiment will be described with reference to FIG. 10, FIG. 2, and FIG.
  • the master key generation process is executed by the master key generation unit 21 of the key generation apparatus 10 belonging to each group at the time of system setup or the like.
  • Step S11 Security parameter reception process
  • the security parameter accepting unit 211 accepts the security parameter ⁇ input by the administrator of the group to which the key generation device 10 belongs via the communication interface 14.
  • the security parameter accepting unit 211 writes the accepted security parameter ⁇ into the memory 12.
  • the security parameter ⁇ is information for determining the security of the master secret key.
  • Step S12 Master key generation process
  • the key generation unit 212 executes the master key generation algorithm with the security parameter ⁇ received in step S11 as an input, and generates a pair of the public key pk and the master secret key msk.
  • the key generation unit 212 reads the security parameter ⁇ from the memory 12.
  • the key generation unit 212 executes the master key generation algorithm with the read security parameter ⁇ as an input, and generates a pair of the public key pk and the master secret key msk.
  • As the master key generation algorithm a policy-based signature master key generation algorithm using non-interactive zero knowledge proof described in Non-Patent Document 2 can be used.
  • the key generation unit 212 writes the generated public key pk and master secret key msk pair in the memory 12.
  • Step S13 Master key output process
  • the key output unit 213 outputs a pair of the public key pk and the master secret key msk generated in step S12. Specifically, the key output unit 213 reads a pair of the public key pk and the master secret key msk from the memory 12. The key output unit 213 writes the read public key pk and master secret key msk pair in the master key storage unit 131. Further, the key output unit 213 transmits the public key pk to the communication device 30 belonging to the same group as the key generation device 10 via the communication interface 14.
  • a user key generation process that is an operation of the user key generation unit 22 according to the first embodiment will be described with reference to FIG. 11 and FIGS.
  • the user key generation process is executed each time a new user secret key sk ⁇ is required by the user key generation unit 22 of the key generation apparatus 10 belonging to each group.
  • Step S21 Master key acquisition process
  • the master key acquisition unit 221 acquires the master secret key msk generated in step S12. Specifically, the master key acquisition unit 221 reads the master secret key msk from the master key storage unit 131. The master key acquisition unit 221 writes the read master secret key msk in the memory 12.
  • Step S22 Policy reception process
  • the policy accepting unit 222 accepts the policy ⁇ input by the manager of the group to which the key generation apparatus 10 belongs via the communication interface 14.
  • the policy receiving unit 222 writes the received policy ⁇ into the memory 12.
  • the policy ⁇ is information that restricts the signature target, and is information that is determined according to the user who uses the user secret key sk ⁇ .
  • the policy ⁇ indicates that the signature can be made if the contract amount in the transaction is equal to or less than the reference amount, and that the signature cannot be made if the amount exceeds the reference amount.
  • it is possible to sign if the partner of the transaction is a designated company, and signing is impossible if the partner is not a designated company.
  • Step S23 User private key generation process
  • the key generation unit 223 receives the master secret key msk acquired in step S21 and the policy ⁇ accepted in step S22, executes a user secret key generation algorithm, and sets the user secret key in which the policy ⁇ is set. sk ⁇ is generated. Specifically, the key generation unit 223 reads the master secret key msk and the policy ⁇ from the memory 12. The key generation unit 223 receives the read master secret key msk and the policy ⁇ , executes a user secret key generation algorithm, and generates a user secret key sk ⁇ set with the policy ⁇ . As the user secret key generation algorithm, the user key generation algorithm for policy-based signature described in Non-Patent Document 2 can be used. The key generation unit 223 writes the generated user secret key sk ⁇ into the memory 12.
  • Step S24 User private key output process
  • the key output unit 224 outputs the user secret key sk ⁇ generated in step S23. Specifically, the key output unit 224 reads the user secret key sk ⁇ from the memory 12. The key output unit 224 writes the user secret key sk ⁇ into the user key storage unit 132. The key output unit 224 secretly transmits the user secret key sk ⁇ to the communication device 30 used by the user via the communication interface 14. As a specific example, the key output unit 224 encrypts the user secret key sk ⁇ by an existing encryption method and transmits the encrypted user secret key sk ⁇ to the communication device 30. Alternatively, the key output unit 224 transmits the user secret key sk ⁇ to the communication device 30 via a secure transmission path.
  • the transaction generation process which is the operation
  • the transaction generation process is executed by the transaction generation unit 41 of the communication device 30 that belongs to the group that executed the transaction.
  • Step S31 User key acquisition process
  • the user key acquisition unit 411 acquires the user secret key sk ⁇ output in step S24. Specifically, the user key acquisition unit 411 receives the user secret key sk ⁇ via the communication interface 34. The user key acquisition unit 411 writes the acquired user secret key sk ⁇ into the memory 32. If the user secret key sk ⁇ is encrypted, the user key acquisition unit 411 decrypts it and writes it into the memory 32.
  • Step S32 content acceptance process
  • the content receiving unit 412 receives the transaction content txc input by the user of the user secret key sk ⁇ acquired in step S31 via the communication interface 34.
  • the content receiving unit 412 writes the received transaction content txc in the memory 32.
  • the transaction content txc includes an original identifier that can uniquely specify the original transaction, a target identifier that can uniquely specify the target transaction, and transaction information.
  • the transaction information includes the contents to be traded and the public key pk of the group of the other party to trade.
  • the contents to be traded are arbitrarily determined according to the purpose of use of the distributed ledger system 1.
  • the contents to be traded indicate the transfer of tokens such as cryptocurrencies and the transfer of assets such as stocks or real estate.
  • Step S33 Signature generation processing
  • the signature generation unit 413 generates a signature ⁇ for the transaction information included in the transaction content txc accepted in step S32, using the user secret key sk ⁇ acquired in step S31. Specifically, the signature generation unit 413 reads the user secret key sk ⁇ and the transaction content txc from the memory 32. Using the read user secret key sk ⁇ , the signature generation unit 413 generates a signature ⁇ by executing a signature generation algorithm on the transaction information included in the read transaction content txc.
  • the signature generation unit 413 uses the user secret key sk ⁇ generated based on the master secret key msk that is paired with the public key pk in the group to which the signature belongs and the policy ⁇ that restricts the signature target,
  • the signature ⁇ is generated for the transaction information including the public key pk of the destination group.
  • the signature generation algorithm the signature generation algorithm in the policy-based signature described in Non-Patent Document 2 can be used.
  • the signature generation unit 413 writes the generated signature ⁇ in the memory 32.
  • the signature generation unit 413 may perform processing as follows. First, the signature generation unit 413 determines whether or not the transaction information included in the transaction content txc is a signature target of the policy ⁇ set in the user secret key sk ⁇ . That is, the signature generation unit 413 determines whether or not the transaction information satisfies a condition that the policy ⁇ is a signature target.
  • the signature generation unit 413 generates a signature ⁇ when the transaction information is a signature target of the policy ⁇ .
  • the signature generation unit 413 outputs an error without generating the signature ⁇ , and ends the transaction generation process.
  • the signature generation unit 413 generates the signature ⁇ only for transaction information. However, the signature generation unit 413 may generate the signature ⁇ for the entire transaction content txc.
  • Step S34 Transaction output process
  • the transaction output unit 414 outputs a transaction tx including the transaction content txc accepted in step S32 and the signature ⁇ generated in step S33. That is, the transaction output unit 414 includes an original identifier that can uniquely identify the original transaction, a target identifier that can uniquely identify the target transaction, transaction information, and the signature ⁇ generated by the signature generation unit 413. Output transaction tx. Specifically, the transaction output unit 414 reads the transaction content txc and the signature ⁇ from the memory 32. The transaction output unit 414 transmits the read transaction content txc and the signature ⁇ as a transaction tx to other groups including the transaction partner group via the communication interface 34.
  • the transaction verification process which is operation
  • the transaction verification process is executed by the transaction verification unit 42 of the communication device 30 when a new transaction tx is received from the communication device 30 belonging to another group.
  • Step S41 Transaction acquisition process
  • the transaction acquisition unit 421 acquires the transaction tx output by the communication device 30 belonging to another group in step S34. Specifically, the transaction acquisition unit 421 receives the transaction tx output by the communication device 30 belonging to another group via the communication interface 34.
  • the transaction acquisition unit 421 writes the acquired transaction tx in the transaction storage unit 331 and the memory 32. Further, the transaction acquisition unit 421 reads the transaction tx specified by the original identifier included in the acquired transaction tx from the transaction storage unit 331, and writes it in the memory 32 as the original transaction ptx.
  • Step S42 content verification process
  • the content verification unit 422 verifies the validity of the transaction content included in the transaction tx acquired in step S41.
  • the contents to be verified are arbitrarily determined according to the purpose of use of the distributed ledger system 1.
  • the content verification unit 422 verifies whether or not the amount to be transferred exceeds the amount transferred in the original transaction ptx when the transaction content is the transfer of the cryptocurrency.
  • the content verification unit 422 determines that the transfer is valid if the amount to be transferred does not exceed the transferred amount, and determines that the transfer is not valid if the amount to be transferred exceeds the transferred amount.
  • the content verification unit 422 verifies whether the asset to be transferred is an asset transferred in the original transaction ptx. The content verification unit 422 determines that the asset to be transferred is valid if it is the transferred asset, and determines that the asset to be transferred is not valid if the asset to be transferred is not the transferred asset. If the content verification unit 422 determines that there is validity, the process proceeds to step S43. If the content verification unit 422 determines that there is no validity, the content verification unit 422 writes a value “0” indicating a verification failure in the memory 32. The process proceeds to step S44.
  • Step S43 Signature verification process
  • the signature verification unit 423 verifies the validity of the signature ⁇ included in the transaction tx acquired in step S41. Specifically, the signature verification unit 423 reads the transaction tx and the original transaction ptx from the memory 32. The signature verification unit 423 inputs the signature ⁇ included in the transaction tx and the public key pk of the counterparty group included in the original transaction ptx, and executes the signature verification algorithm to verify the validity of the signature ⁇ . Validate.
  • the signature verification algorithm the signature verification algorithm in the policy-based signature described in Non-Patent Document 2 can be used. That is, as shown in FIG.
  • the signature verification unit 423 verifies the signature ⁇ included in the transaction tx with the public key pk of the counterpart party included in the original transaction ptx. When the validity of the signature ⁇ can be confirmed, the signature verification unit 423 writes a value “1” indicating the verification success to the memory 32, and when the validity of the signature ⁇ cannot be confirmed, the value indicating the verification failure. “0” is written to the memory 32.
  • Step S44 Result output process
  • the result output unit 424 outputs the verification result performed in step S42 or step S43. Specifically, the result output unit 424 reads a value indicating a verification success or a verification failure as a verification result from the memory 32. Then, the result output unit 424 writes the read verification result in the transaction storage unit 331 in association with the transaction tx acquired in step S41.
  • the block generation processing is executed by the block generation unit 43 of the communication device 30 at regular intervals such as every 10 minutes.
  • Step S51 Transaction collection process
  • the transaction collection unit 431 reads a transaction set txs that is a set of transactions tx from the transaction storage unit 331.
  • the transaction collection unit 431 among the plurality of transactions tx stored in the transaction storage unit 331, the verification result is a verification success, and all the transactions tx that are not processed in the past block generation process Is read as a transaction set txs.
  • the transaction collection unit 431 writes the read transaction set txs in the memory 32.
  • Step S52 Block generation processing
  • the block generation unit 432 generates a block bc from the transaction set txs read in step S51. Specifically, the block generation unit 432 reads the transaction set txs from the memory 32. The block generation unit 432 generates a block bc by executing a consensus algorithm with the read transaction set txs as an input. As the consensus algorithm, the PROOF OF WORK algorithm described in Non-Patent Document 1 can be used. The block generation unit 432 writes the generated block bc in the memory 32.
  • Non-Patent Document 1 a nonce value is randomly calculated, and the read transaction set txs and the hash value of the block bc generated by the block generation process executed last time are calculated.
  • a hash value is calculated as an input to the hash function.
  • the nonce value is changed and the hash value is recalculated until the calculated hash value is equal to or less than the reference value.
  • a block bc is obtained by combining the transaction set txs, the hash value of the block bc generated by the block generation process executed last time, and the nonce value.
  • Step S53 Block output process
  • the block output unit 433 outputs the block bc generated in step S52. Specifically, the block output unit 433 reads the block bc from the memory 32 and transmits it to the other communication device 30 via the communication interface 34.
  • the other communication devices 30 include not only the communication devices 30 belonging to the same group but also the communication devices 30 belonging to other groups.
  • the block verification process which is operation
  • the block verification process is executed by the block verification unit 44 of the communication device 30 when a new block bc is received from another communication device 30.
  • Step S61 Block acquisition process
  • the block acquisition unit 441 acquires the block bc output in step S53. Specifically, the block acquisition unit 441 receives the block bc via the communication interface 14. The block acquisition unit 441 writes the acquired block bc in the memory 32.
  • Step S62 Block verification process
  • the block verification unit 442 verifies the validity of the block bc acquired in step S61. Specifically, the block verification unit 442 reads the block bc from the memory 32. The block verification unit 442 receives the read block bc as an input, executes a verification algorithm corresponding to the consensus algorithm used in step S52, and verifies the validity of the block bc. As the verification algorithm, the PROOF OF WORK algorithm described in Non-Patent Document 1 can be used. The block verification unit 442 writes a value “1” indicating the verification success to the memory 32 when the validity of the block bc can be confirmed, and indicates a verification failure when the validity of the block bc cannot be confirmed. “0” is written to the memory 32.
  • a hash value is calculated using the block bc as an input of a hash function.
  • the correctness is confirmed, and when the calculated hash value is larger than the reference value, the correctness is not confirmed.
  • Step S63 Result output process
  • the result output unit 443 writes the block bc acquired in step 61 in the block storage unit 332 when the validity is confirmed in step S62.
  • the result output unit 443 discards the block bc acquired in step 61.
  • the result output unit 443 reads a value indicating a verification success or a verification failure, which is a verification result, from the memory 32.
  • the result output unit 443 reads the block bc from the memory 32 and writes it to the block storage unit 332 when the read verification result indicates a verification success.
  • the result output unit 443 deletes the block bc from the memory 32 when the read verification result indicates a verification failure.
  • Embodiment 1 *** Effects of Embodiment 1 *** As described above, in the distributed ledger system 1 according to the first embodiment, a pair of the public key pk and the master secret key msk is generated for each group. In each group, a policy ⁇ is determined for each user, and a user secret key sk ⁇ in which the policy ⁇ is set is generated. Thereby, the authority for every user in the transaction by the block chain between the groups which consist of a plurality of users is controllable.
  • an accounting person who has received a secret key from the accounting department manager can generate a signature for any content. Therefore, the accounting staff can make a transaction with any content. For example, it is possible to carry out a large transaction such as payment of 1 billion yen to Company X.
  • the accounting department manager can set a policy ⁇ that restricts a signature object for each user and can generate a user secret key sk ⁇ . Therefore, for example, it is possible to generate a user secret key sk ⁇ in which the subject of signing is limited to “a transaction of 1 million yen or less with Company X or Company Y” for the accounting staff.
  • the accountant can generate a signature for a transaction of 1 million yen payment to Company X, so that a signature can be generated.
  • a transaction of 2 million yen payment to B company and a transaction of 1 million yen payment to C company cannot be performed because a signature cannot be generated.
  • the counterparty of the transaction can confirm that the user belonging to the group has generated the signature by verifying the signature.
  • the other party of the transaction cannot confirm which of the users belonging to the group has generated the signature.
  • information indicating which user belongs to which group does not leak to other groups.
  • the distributed ledger system 1 it is only necessary to generate one signature even when a transaction is performed with a group of a plurality of users as a partner. That is, unlike the prior art, it is not necessary to generate a signature for each user as a counterpart. Therefore, it is possible to shorten the signature generation time. Similarly, it is only necessary to include the public key of the partner group in the transaction, and it is not necessary to include the public key of each user as the partner in the transaction. Therefore, it does not take time to acquire a public key. In addition, the transaction data size can be reduced.
  • the distributed ledger system 1 includes the key generation device 10 for each group.
  • the distributed ledger system 1 may include a key generation device 10 common to each group.
  • the key generation device 10 generates a pair of a separate public key pk and master secret key msk for each group.
  • the key generation device 10 generates the user secret key sk ⁇ using the master secret key msk of the group to which the user belongs.
  • the key generation device 10 includes a master key generation unit 21 and a user key generation unit 22.
  • the master key generation unit 21 and the user key generation unit 22 may be provided in different devices.
  • the communication device 30 includes a transaction generation unit 41, a transaction verification unit 42, a block generation unit 43, and a block verification unit 44.
  • another apparatus may include the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44.
  • the communication device 30X may include only the transaction generation unit 41 and the transaction verification unit 42
  • the communication device 30Y may include only the block generation unit 43 and the block verification unit 44.
  • the communication device 30Z belonging to the same group as the communication device 30X and the communication device 30Y may include a transaction generation unit 41, a transaction verification unit 42, a block generation unit 43, and a block verification unit 44.
  • the functions of the master key generation unit 21 and the user key generation unit 22 of the key generation device 10 are realized by software. Moreover, the function of the transaction generation part 41 of the communication apparatus 30, the transaction verification part 42, the block generation part 43, and the block verification part 44 was implement
  • the key generation device 10 includes a processing circuit 15 instead of the processor 11.
  • the processing circuit 15 is a dedicated electronic circuit that realizes the functions of the master key generation unit 21 and the user key generation unit 22.
  • the communication device 30 includes a processing circuit 35 instead of the processor 31.
  • the processing circuit 35 is a dedicated electronic circuit that realizes the functions of the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44.
  • the processing circuits 15 and 35 are a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA (Gate Array), an ASIC (Application Specific Integrated Circuit), and an FPGA (Field-Programmable Gate Array). Is assumed.
  • the functions of the master key generation unit 21 and the user key generation unit 22 may be realized by one processing circuit 15, and the functions of the master key generation unit 21 and the user key generation unit 22 are distributed to a plurality of processing circuits 15. May be realized.
  • the functions of the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44 may be realized by one processing circuit 35, or the transaction generation unit 41, the transaction verification unit 42, and the block The functions of the generation unit 43 and the block verification unit 44 may be realized by being distributed to a plurality of processing circuits 35.
  • ⁇ Modification 4> As a fourth modification, some functions may be realized by hardware, and other functions may be realized by software. That is, some of the functions of the master key generation unit 21, the user key generation unit 22, the transaction generation unit 41, the transaction verification unit 42, the block generation unit 43, and the block verification unit 44 are realized by hardware. The function may be realized by software.
  • the processors 11 and 31, the memories 12 and 32, the storages 13 and 33, and the processing circuits 15 and 35 are collectively referred to as “processing circuitry”. That is, the function of each functional component is realized by the processing circuitry.
  • Embodiment 2 is different from the first embodiment in that an attribute-based signature, which is a special policy-based signature, is used as a signature method. In the second embodiment, this different point will be described, and the description of the same point will be omitted.
  • an attribute-based signature which is a special policy-based signature
  • the operation of the distributed ledger system 1 according to the second embodiment will be described with reference to FIGS. 10 to 12, FIG. 14, and FIGS. 22 to 23.
  • the operation of the key generation device 10 in the distributed ledger system 1 according to the second embodiment corresponds to the key generation method according to the second embodiment.
  • the operation of the key generation apparatus 10 in the distributed ledger system 1 according to the second embodiment corresponds to the processing of the key generation program according to the second embodiment.
  • the operation of the communication device 30 in the distributed ledger system 1 according to the second embodiment corresponds to the communication method according to the second embodiment.
  • the operation of the communication device 30 in the distributed ledger system 1 according to the second embodiment corresponds to the processing of the communication program according to the second embodiment.
  • an attribute-based signature is used as a signature scheme.
  • user attribute information is set as a policy ⁇ in the user secret key sk ⁇ , and a logical expression indicating an attribute condition necessary for the signer is included in the data to be signed.
  • a logical expression indicating an attribute condition necessary for the signer is included in the data to be signed.
  • step S11 and step S13 are the same as those in the first embodiment.
  • Step S12 Master key generation process
  • the key generation unit 212 executes a master key generation algorithm in the attribute-based signature to generate a pair of the public key pk and the master secret key msk.
  • the master key generation algorithm in the attribute-based signature the master key generation algorithm described in Patent Document 1 can be used.
  • step S21 and step S24 are the same as those in the first embodiment.
  • Step S22 Policy reception process
  • Policy accepting unit 222 accepts policy ⁇ .
  • the policy ⁇ is attribute information of a user who uses the user secret key sk ⁇ .
  • the policy ⁇ is information such as the user's affiliation, gender, age, and address.
  • Step S23 User private key generation process
  • the key generation unit 223 executes a user secret key generation algorithm in the attribute-based signature to generate a user secret key sk ⁇ in which attribute information that is a policy ⁇ is set.
  • the user secret key generation algorithm in the attribute-based signature the user secret key generation algorithm described in Patent Document 1 can be used.
  • step S31 and step S34 are the same as those in the first embodiment.
  • Step S32 content acceptance process
  • the content receiving unit 412 receives the transaction content txt.
  • the transaction information included in the transaction content txc includes, in addition to the transaction content txc in the first embodiment, a logical expression that the signer satisfies and a logical expression that the next transaction satisfies.
  • the logical expression satisfied by the signer indicates an attribute condition necessary for the user to generate a correct signature for the transaction information.
  • a logical expression that is satisfied by the next trader included in the original transaction ptx indicated by the original identifier is set in the logical expression that is satisfied by the signer.
  • the logical expression satisfied by the next trader indicates an attribute condition necessary for a user who performs a new transaction based on the transaction tx including the transaction content txc to generate a correct signature.
  • the logical expression satisfied by the signer is “Company X AND Accounting Department”, and the logical expression satisfied by the next trader is “Y Company AND General Affairs Department”.
  • the logical expression satisfied by the signer in the new transaction with the transaction tx as the original transaction is “Y Company AND General Affairs Department”.
  • the signature generation unit 413 generates a signature ⁇ by executing a signature generation algorithm in the attribute-based signature.
  • the signature generation algorithm in the attribute-based signature the signature generation algorithm described in Patent Document 1 can be used.
  • a correct signature can be generated only when the attribute information set in the user secret key sk ⁇ satisfies the attribute condition indicated by the logical expression satisfied by the signer included in the transaction information. In other words, if the logical expression satisfied by the signer is “Company X AND Accounting Department”, a correct signature is generated for the transaction tx only with the user secret key sk ⁇ set with attribute information satisfying “Company X AND Accounting Department”. It becomes possible to do.
  • step S41 to step S42 and step S44 is the same as in the first embodiment.
  • Step S43 Signature verification process
  • the signature verification unit 423 executes a signature verification algorithm in the attribute-based signature to verify the validity of the signature ⁇ .
  • the signature verification algorithm in the attribute-based signature the signature verification algorithm described in Patent Document 1 can be used.
  • the other party of the transaction can confirm that the signature has been signed by the user who satisfies the logical expression that the signer satisfies by verifying the signature. .
  • the other party of the transaction cannot specify the attribute information of the user who generated the signature.

Abstract

分散型元帳システム（１）では、鍵生成装置（１０）によって、グループ毎に公開鍵とマスター秘密鍵とのペアが生成される。また、鍵生成装置（１０）によって、各グループのマスター秘密鍵により、そのグループに属するユーザ毎に、署名対象を制限するポリシーが設定されたユーザ秘密鍵が生成される。各グループの通信装置（３０）は、ユーザ秘密鍵を用いて、取引する内容と送信先グループの公開鍵とを含む取引情報に対して署名を生成し、生成された署名と取引情報とを含む取引を他の通信装置（３０）に出力する。

Description

通信装置及び分散型元帳システム
　この発明は、複数人取引を容易にする分散型元帳システムと、分散型元帳システムにおける通信装置とに関する。
　ブロックチェーンは、暗号通貨であるビットコイン（登録商標）の中核をなす技術であり、非特許文献１において提案された。
　ブロックチェーンは、電子署名を利用したユーザ間での取引記録を複数まとめたブロックをハッシュ関数により連鎖させる。これにより、ブロックチェーンは、連続した取引記録の集合である元帳の改ざんを防ぐとともに、互いに信頼できない複数のユーザ間で元帳を分散管理することを可能にしている。
　ブロックチェーンの各取引は、元取引と、取引内容と、送信元ユーザの電子署名と、送信先ユーザの公開鍵との４要素により構成される。各取引の正当性は、送信元ユーザの電子署名を、元取引における送信先ユーザの公開鍵で検証することで確かめられる。これにより、各取引でやり取りされた内容を次の取引に使用することができるのは、送信先ユーザの公開鍵に対応した秘密鍵を持つユーザのみとなり、取引を行うことが可能なユーザを正しく制御することが可能となる。
　ビットコイン（登録商標）においては、各取引の内容は、ユーザからユーザへのＢＴＣという単位の暗号通貨の譲渡である。送信元ユーザは、送信元ユーザの公開鍵が送信先ユーザの公開鍵として設定された取引を元取引とし、取引内容として譲渡するＢＴＣの数量を指定し、送信元ユーザの秘密鍵を使用して電子署名を生成し、送信先ユーザの公開鍵を指定することでＢＴＣを支払う取引を作成する。
特開２０１２－１５５０８８号公報
Ｎ．ＳＡＴＯＳＨＩ「Ｂｉｔｃｏｉｎ：　Ａ　Ｐｅｅｒ－ｔｏ－Ｐｅｅｒ　Ｅｌｅｃｔｒｏｎｉｃ　Ｃａｓｈ　Ｓｙｓｔｅｍ」 Ｍ．ＢＥＬＬＡＲＥ，Ｇ．ＦＵＣＨＳＢＡＵＥＲ．　「Ｐｏｌｉｃｙ－ｂａｓｅｄ　ｓｉｇｎａｔｕｒｅｓ」Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｐｒａｃｔｉｃｅ　ａｎｄ　Ｔｈｅｏｒｙ　ｉｎ　Ｐｕｂｌｉｃ－Ｋｅｙ　Ｃｒｙｐｔｏｇｒａｐｈｙ　２０１４，ＬＮＣＳ　８３８３，ｐ５２０－５３７，２０１４
　ビットコイン（登録商標）におけるブロックチェーンには、電子署名の秘密鍵及び公開鍵が単一のペアとして紐づいているため、複数ユーザからなるグループ間での取引に適さないという課題があった。
　具体的には、会社間で取引を行う際に、取引相手である会社の複数のユーザを対象として取引を行うためには、対象となる全てのユーザの公開鍵を送信先ユーザの公開鍵として取引に含めなければならない。そのため、ブロックチェーンを記憶するデータ領域の増大と、取引に含める公開鍵を特定する手間の増大といった課題が発生する。また、複数の公開鍵が送信先ユーザの公開鍵として含められた取引を元取引として新たな取引を行うと、新たな取引に含まれた電子署名を検証することによって、複数の公開鍵のうちどの公開鍵に対応したユーザによって新たな取引が作成されたかが特定されてしまうという匿名性の課題もある。
　これらの課題を解決するために複数のユーザで単一の秘密鍵を共有して利用することが考えられる。しかし、この場合には、各ユーザが同一の権限を持ち、自由に取引を行えてしまうという別の課題が発生してしまう。つまり、この場合には、ユーザ毎に権限を設け、取引内容を制限するというようなことができない。
　この発明は、複数のユーザからなるグループ間でブロックチェーンによる取引を行う場合に、ユーザ毎の権限を制御可能にすることを目的とする。
　この発明に係る通信装置は、
　属するグループにおける公開鍵の対となるマスター秘密鍵と、署名対象を制限するポリシーとに基づき生成されたユーザ秘密鍵を用いて、取引する内容と、送信先のグループの公開鍵とを含む取引情報に対して署名を生成する署名生成部と、
　前記署名生成部によって生成された署名と、前記取引情報とを含む取引を出力する取引出力部と
を備える。
　この発明では、署名対象を制限するポリシーに基づき生成されたユーザ秘密鍵を用いて署名を生成する。これにより、複数のユーザからなるグループ間でブロックチェーンによる取引を行う場合に、ユーザ毎の権限を制御可能である。
実施の形態１に係る分散型元帳システム１の構成図。 実施の形態１に係る鍵生成装置１０の構成図。 実施の形態１に係るマスター鍵生成部２１の構成図。 実施の形態１に係るユーザ鍵生成部２２の構成図。 実施の形態１に係る通信装置３０の構成図。 実施の形態１に係る取引生成部４１の構成図。 実施の形態１に係る取引検証部４２の構成図。 実施の形態１に係るブロック生成部４３の構成図。 実施の形態１に係るブロック検証部４４の構成図。 実施の形態１に係るマスター鍵生成処理のフローチャート。 実施の形態１に係るユーザ鍵生成処理のフローチャート。 実施の形態１に係る取引生成処理のフローチャート。 実施の形態１に係る取引ｔｘの説明図。 実施の形態１に係る取引検証処理のフローチャート。 実施の形態１に係る取引ｔｘの流れを示す図。 実施の形態１に係るブロック生成処理のフローチャート。 実施の形態１に係るブロック検証処理のフローチャート。 実施の形態１におけるユーザ毎の権限制御の説明図。 変形例１に係る分散型元帳システム１の構成図。 変形例３に係る鍵生成装置１０の構成図。 変形例３に係る通信装置３０の構成図。 実施の形態２に係る取引ｔｘの説明図。 実施の形態２に係る取引ｔｘの流れを示す図。 実施の形態２におけるユーザ毎の権限制御の説明図。
　実施の形態１．
　＊＊＊構成の説明＊＊＊
　図１を参照して、実施の形態１に係る分散型元帳システム１の構成を説明する。
　分散型元帳システム１は、複数のグループそれぞれに属する鍵生成装置１０及び１台以上の通信装置３０を備える。各グループは、１人以上のユーザが所属している。
　各グループの通信装置３０は、ネットワーク５０を介して接続されており、互いに通信可能である。また、各グループに属する鍵生成装置１０と通信装置３０とは伝送路を介して接続されており、通信可能である。
　図２を参照して、実施の形態１に係る鍵生成装置１０の構成を説明する。
　鍵生成装置１０は、パーソナルコンピュータとワークステーションといったコンピュータである。
　鍵生成装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信インタフェース１４とのハードウェアを備える。プロセッサ１１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
　鍵生成装置１０は、機能構成要素として、マスター鍵生成部２１と、ユーザ鍵生成部２２とを備える。マスター鍵生成部２１と、ユーザ鍵生成部２２との機能はソフトウェアにより実現される。
　ストレージ１３には、マスター鍵生成部２１と、ユーザ鍵生成部２２との機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ１１によりメモリ１２に読み込まれ、プロセッサ１１によって実行される。これにより、マスター鍵生成部２１と、ユーザ鍵生成部２２との機能が実現される。
　また、ストレージ１３は、マスター鍵記憶部１３１と、ユーザ鍵記憶部１３２との機能を実現する。
　図３を参照して、実施の形態１に係るマスター鍵生成部２１の構成を説明する。
　マスター鍵生成部２１は、セキュリティパラメータ受付部２１１と、鍵生成部２１２と、鍵出力部２１３とを備える。
　図４を参照して、実施の形態１に係るユーザ鍵生成部２２の構成を説明する。
　ユーザ鍵生成部２２は、マスター鍵取得部２２１と、ポリシー受付部２２２と、鍵生成部２２３と、鍵出力部２２４とを備える。
　図５を参照して、実施の形態１に係る通信装置３０の構成を説明する。
　通信装置３０は、パーソナルコンピュータとワークステーションとスマートフォンとタブレット端末といったコンピュータである。
　通信装置３０は、プロセッサ３１と、メモリ３２と、ストレージ３３と、通信インタフェース３４とのハードウェアを備える。プロセッサ３１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
　通信装置３０は、機能構成要素として、取引生成部４１と、取引検証部４２と、ブロック生成部４３と、ブロック検証部４４とを備える。取引生成部４１と、取引検証部４２と、ブロック生成部４３と、ブロック検証部４４との機能はソフトウェアにより実現される。
　ストレージ３３には、取引生成部４１と、取引検証部４２と、ブロック生成部４３と、ブロック検証部４４との機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ３１によりメモリ３２に読み込まれ、プロセッサ３１によって実行される。これにより、取引生成部４１と、取引検証部４２と、ブロック生成部４３と、ブロック検証部４４との機能が実現される。
　また、ストレージ３３は、取引記憶部３３１と、ブロック記憶部３３２との機能を実現する。
　図６を参照して、実施の形態１に係る取引生成部４１の構成を説明する。
　取引生成部４１は、ユーザ鍵取得部４１１と、内容受付部４１２と、署名生成部４１３と、取引出力部４１４とを備える。
　図７を参照して、実施の形態１に係る取引検証部４２の構成を説明する。
　取引検証部４２は、取引取得部４２１と、内容検証部４２２と、署名検証部４２３と、結果出力部４２４とを備える。
　図８を参照して、実施の形態１に係るブロック生成部４３の構成を説明する。
　ブロック生成部４３は、取引収集部４３１と、ブロック生成部４３２と、ブロック出力部４３３とを備える。
　図９を参照して、実施の形態１に係るブロック検証部４４の構成を説明する。
　ブロック検証部４４は、ブロック取得部４４１と、ブロック検証部４４２と、結果出力部４４３とを備える。
　プロセッサ１１，３１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）である。プロセッサ１１，３１は、具体例としては、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。
　メモリ１２，３２は、データを一時的に記憶する記憶装置である。メモリ１２，３２は、具体例としては、ＳＲＡＭ（Ｓｔａｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。
　ストレージ１３，３３は、データを保管する記憶装置である。ストレージ１３は、具体例としては、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）である。また、ストレージ１３，３３は、ＳＤ（登録商標，Ｓｅｃｕｒｅ　Ｄｉｇｉｔａｌ）メモリカード、ＣＦ（ＣｏｍｐａｃｔＦｌａｓｈ）、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）といった可搬記憶媒体であってもよい。
　通信インタフェース１４，３４は、外部の装置と通信するためのインタフェースである。通信インタフェース１４，３４は、具体例としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）、ＨＤＭＩ（登録商標，Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｒｆａｃｅ）のポートである。
　図２では、プロセッサ１１は、１つだけ示されている。しかし、鍵生成装置１０は、プロセッサ１１を代替する複数のプロセッサを備えていてもよい。同様に、通信装置３０は、プロセッサ３１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、各機能構成要素の機能を実現するプログラムの実行を分担する。それぞれのプロセッサは、プロセッサ１１，３１と同じように、プロセッシングを行うＩＣである。
　＊＊＊動作の説明＊＊＊
　図１０から図１７を参照して、実施の形態１に係る分散型元帳システム１の動作を説明する。
　実施の形態１に係る分散型元帳システム１における鍵生成装置１０の動作は、実施の形態１に係る鍵生成方法に相当する。また、実施の形態１に係る分散型元帳システム１における鍵生成装置１０の動作は、実施の形態１に係る鍵生成プログラムの処理に相当する。
　実施の形態１に係る分散型元帳システム１における通信装置３０の動作は、実施の形態１に係る通信方法に相当する。また、実施の形態１に係る分散型元帳システム１における通信装置３０の動作は、実施の形態１に係る通信プログラムの処理に相当する。
　実施の形態１では、署名方式として、ポリシーベース署名を用いる。ポリシーベース署名では、ユーザ秘密鍵ｓｋΓに署名対象を制限するポリシーΓが設定されており、ポリシーΓが署名対象とするデータに対してのみ正しい署名を生成することが可能である。
　図１０と、図２及び図３とを参照して、実施の形態１に係るマスター鍵生成部２１の動作であるマスター鍵生成処理を説明する。
　マスター鍵生成処理は、各グループに属する鍵生成装置１０のマスター鍵生成部２１によって、システムのセットアップ時等に実行される。
　（ステップＳ１１：セキュリティパラメータ受付処理）
　セキュリティパラメータ受付部２１１は、通信インタフェース１４を介して、鍵生成装置１０が属するグループの管理者等によって入力されたセキュリティパラメータλを受け付ける。セキュリティパラメータ受付部２１１は、受け付けられたセキュリティパラメータλをメモリ１２に書き込む。
　セキュリティパラメータλは、マスター秘密鍵の安全性を決めるための情報である。
　（ステップＳ１２：マスター鍵生成処理）
　鍵生成部２１２は、ステップＳ１１で受け付けられたセキュリティパラメータλを入力として、マスター鍵生成アルゴリズムを実行して、公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを生成する。
　具体的には、鍵生成部２１２は、メモリ１２からセキュリティパラメータλを読み出す。鍵生成部２１２は、読み出されたセキュリティパラメータλを入力としてマスター鍵生成アルゴリズムを実行して、公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを生成する。マスター鍵生成アルゴリズムとしては、非特許文献２に記載された、非対話ゼロ知識証明を用いたポリシーベース署名のマスター鍵生成アルゴリズムを用いることができる。鍵生成部２１２は、生成された公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアをメモリ１２に書き込む。
　（ステップＳ１３：マスター鍵出力処理）
　鍵出力部２１３は、ステップＳ１２で生成された公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを出力する。
　具体的には、鍵出力部２１３は、メモリ１２から公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを読み出す。鍵出力部２１３は、読み出された公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアをマスター鍵記憶部１３１に書き込む。また、鍵出力部２１３は、通信インタフェース１４を介して、鍵生成装置１０と同じグループに属する通信装置３０に公開鍵ｐｋを送信する。
　図１１と、図２及び図４とを参照して、実施の形態１に係るユーザ鍵生成部２２の動作であるユーザ鍵生成処理を説明する。
　ユーザ鍵生成処理は、各グループに属する鍵生成装置１０のユーザ鍵生成部２２によって、新たなユーザ秘密鍵ｓｋΓが必要になる度に実行される。
　（ステップＳ２１：マスター鍵取得処理）
　マスター鍵取得部２２１は、ステップＳ１２で生成されたマスター秘密鍵ｍｓｋを取得する。具体的には、マスター鍵取得部２２１は、マスター鍵記憶部１３１からマスター秘密鍵ｍｓｋを読み出す。マスター鍵取得部２２１は、読み出されたマスター秘密鍵ｍｓｋをメモリ１２に書き込む。
　（ステップＳ２２：ポリシー受付処理）
　ポリシー受付部２２２は、通信インタフェース１４を介して、鍵生成装置１０が属するグループの管理者等によって入力されたポリシーΓを受け付ける。ポリシー受付部２２２は、受け付けられたポリシーΓをメモリ１２に書き込む。
　ポリシーΓは、署名対象を制限する情報であり、ユーザ秘密鍵ｓｋΓを使用するユーザに応じて決められる情報である。具体例としては、ポリシーΓは、取引における契約金額が基準額以下であれば署名可能であり、基準額を超える場合には署名不可能であることを示す。また、他の具体例としては、取引の相手が指定会社であれば署名可能であり、指定会社以外であれば署名不可能であることを示す。
　（ステップＳ２３：ユーザ秘密鍵生成処理）
　鍵生成部２２３は、ステップＳ２１で取得されたマスター秘密鍵ｍｓｋと、ステップＳ２２で受け付けられたポリシーΓとを入力として、ユーザ秘密鍵生成アルゴリズムを実行して、ポリシーΓが設定されたユーザ秘密鍵ｓｋΓを生成する。
　具体的には、鍵生成部２２３は、メモリ１２からマスター秘密鍵ｍｓｋとポリシーΓとを読み出す。鍵生成部２２３は、読み出されたマスター秘密鍵ｍｓｋとポリシーΓとを入力として、ユーザ秘密鍵生成アルゴリズムを実行して、ポリシーΓが設定されたユーザ秘密鍵ｓｋΓを生成する。ユーザ秘密鍵生成アルゴリズムとしては、非特許文献２に記載されたポリシーベース署名のユーザ鍵生成アルゴリズムを用いることができる。鍵生成部２２３は、生成されたユーザ秘密鍵ｓｋΓをメモリ１２に書き込む。
　（ステップＳ２４：ユーザ秘密鍵出力処理）
　鍵出力部２２４は、ステップＳ２３で生成されたユーザ秘密鍵ｓｋΓを出力する。
　具体的には、鍵出力部２２４は、メモリ１２からユーザ秘密鍵ｓｋΓを読み出す。鍵出力部２２４は、ユーザ秘密鍵ｓｋΓをユーザ鍵記憶部１３２に書き込む。また、鍵出力部２２４は、通信インタフェース１４を介してユーザが使用する通信装置３０に秘密裡にユーザ秘密鍵ｓｋΓを送信する。具体例としては、鍵出力部２２４は、既存の暗号方式によりユーザ秘密鍵ｓｋΓを暗号化した上で通信装置３０に送信する。あるいは、鍵出力部２２４は、安全な伝送路を介してユーザ秘密鍵ｓｋΓを通信装置３０に送信する。
　図１２と、図５及び図６とを参照して、実施の形態１に係る取引生成部４１の動作である取引生成処理を説明する。
　取引生成処理は、新たな取引が行われる場合に、取引の実行元のグループに属する通信装置３０の取引生成部４１によって実行される。
　（ステップＳ３１：ユーザ鍵取得処理）
　ユーザ鍵取得部４１１は、ステップＳ２４で出力されたユーザ秘密鍵ｓｋΓを取得する。具体的には、ユーザ鍵取得部４１１は、ユーザ秘密鍵ｓｋΓを通信インタフェース３４を介して受信する。ユーザ鍵取得部４１１は、取得されたユーザ秘密鍵ｓｋΓをメモリ３２に書き込む。なお、ユーザ鍵取得部４１１は、ユーザ秘密鍵ｓｋΓが暗号化されている場合には、復号した上でメモリ３２に書き込む。
　（ステップＳ３２：内容受付処理）
　内容受付部４１２は、通信インタフェース３４を介して、ステップＳ３１で取得されたユーザ秘密鍵ｓｋΓのユーザ等によって入力された取引内容ｔｘｃを受け付ける。内容受付部４１２は、受け付けられた取引内容ｔｘｃをメモリ３２に書き込む。
　図１３に示すように、取引内容ｔｘｃは、元取引を一意に特定可能な元識別子と、対象の取引を一意に特定可能な対象識別子と、取引情報とを含む。取引情報は、取引する内容と、取引する相手先のグループの公開鍵ｐｋとが含まれる。取引する内容は、分散型元帳システム１の使用目的に応じて任意に定められるものである。具体例としては、取引する内容は、暗号通貨等のトークンの譲渡と、株又は不動産といった資産の譲渡といったことを示す。
　（ステップＳ３３：署名生成処理）
　署名生成部４１３は、ステップＳ３１で取得されたユーザ秘密鍵ｓｋΓを用いて、ステップＳ３２で受け付けられた取引内容ｔｘｃに含まれる取引情報に対して署名σを生成する。
　具体的には、署名生成部４１３は、メモリ３２からユーザ秘密鍵ｓｋΓと取引内容ｔｘｃとを読み出す。署名生成部４１３は、読み出されたユーザ秘密鍵ｓｋΓを用いて、読み出された取引内容ｔｘｃに含まれる取引情報に対して、署名生成アルゴリズムを実行することにより、署名σを生成する。つまり、署名生成部４１３は、属するグループにおける公開鍵ｐｋと対を成すマスター秘密鍵ｍｓｋと、署名対象を制限するポリシーΓとに基づき生成されたユーザ秘密鍵ｓｋΓを用いて、取引する内容と、送信先グループの公開鍵ｐｋとを含む取引情報に対して署名σを生成する。署名生成アルゴリズムとしては、非特許文献２に記載されたポリシーベース署名における署名生成アルゴリズムを用いることができる。署名生成部４１３は、生成された署名σをメモリ３２に書き込む。
　ポリシーベース署名では、ポリシーΓが署名対象とするデータに対してのみ正しい署名を生成することが可能である。つまり、ポリシーΓが署名対象としないデータに対して署名を生成すると、後述する署名検証処理で検証に失敗する署名が生成されてしまう。そこで、署名生成部４１３は、以下のように処理を行ってもよい。
　まず、署名生成部４１３は、取引内容ｔｘｃに含まれる取引情報が、ユーザ秘密鍵ｓｋΓに設定されたポリシーΓの署名対象であるか否かを判定する。つまり、署名生成部４１３は、ポリシーΓが署名対象とする条件を取引情報が満たしているか否かを判定する。そして、署名生成部４１３は、取引情報がポリシーΓの署名対象である場合には、署名σを生成する。一方、署名生成部４１３は、取引情報がポリシーΓの署名対象でない場合には、署名σを生成せずエラーを出力して、取引生成処理を終了する。
　上記説明では、署名生成部４１３は、取引情報のみを対象として署名σを生成した。しかし、署名生成部４１３は、取引内容ｔｘｃ全体を対象として署名σを生成してもよい。
　（ステップＳ３４：取引出力処理）
　取引出力部４１４は、図１３に示すように、ステップＳ３２で受け付けられた取引内容ｔｘｃと、ステップＳ３３で生成された署名σとを含む取引ｔｘを出力する。つまり、取引出力部４１４は、元取引を一意に特定可能な元識別子と、対象の取引を一意に特定可能な対象識別子と、取引情報と、署名生成部４１３によって生成された署名σとを含む取引ｔｘを出力する。
　具体的には、取引出力部４１４は、メモリ３２から取引内容ｔｘｃと署名σとを読み出す。取引出力部４１４は、読み出された取引内容ｔｘｃと署名σとを取引ｔｘとして、取引の相手先のグループを含む他のグループに、通信インタフェース３４を介して送信する。
　図１４と、図５及び図７とを参照して、実施の形態１に係る取引検証部４２の動作である取引検証処理を説明する。
　取引検証処理は、他のグループに属する通信装置３０から新たな取引ｔｘが受信された場合に、通信装置３０の取引検証部４２によって実行される。
　（ステップＳ４１：取引取得処理）
　取引取得部４２１は、ステップＳ３４で他のグループに属する通信装置３０により出力された取引ｔｘを取得する。具体的には、取引取得部４２１は、他のグループに属する通信装置３０により出力された取引ｔｘを通信インタフェース３４を介して受信する。取引取得部４２１は、取得された取引ｔｘを取引記憶部３３１とメモリ３２とに書き込む。
　また、取引取得部４２１は、取得された取引ｔｘに含まれる元識別子によって特定される取引ｔｘを取引記憶部３３１から読み出し、元取引ｐｔｘとしてメモリ３２に書き込む。
　（ステップＳ４２：内容検証処理）
　内容検証部４２２は、ステップＳ４１で取得された取引ｔｘに含まれる取引する内容の妥当性を検証する。
　検証する内容は、分散型元帳システム１の使用目的に応じて任意に定められるものである。具体例としては、内容検証部４２２は、取引する内容が暗号通貨の譲渡である場合には、譲渡する額が、元取引ｐｔｘで譲渡された額を上回っていないかを検証する。内容検証部４２２は、譲渡する額が譲渡された額を上回っていなければ妥当性ありと判定し、譲渡する額が譲渡された額を上回っていれば妥当性なしと判定する。また、内容検証部４２２は、取引する内容が株又は不動産といった資産の譲渡である場合には、譲渡する資産が、元取引ｐｔｘで譲渡された資産であるかを検証する。内容検証部４２２は、譲渡する資産が譲渡された資産である場合には妥当性ありと判定し、譲渡する資産が譲渡された資産でない場合には妥当性なしと判定する。
　内容検証部４２２は、妥当性ありと判定した場合には、処理をステップＳ４３に進め、妥当性なしと判定した場合には、検証失敗を示す値“０”をメモリ３２に書き込んだ上で、処理をステップＳ４４に進める。
　（ステップＳ４３：署名検証処理）
　署名検証部４２３は、ステップＳ４１で取得された取引ｔｘに含まれる署名σの正当性を検証する。
　具体的には、署名検証部４２３は、メモリ３２から取引ｔｘと元取引ｐｔｘとを読み出す。署名検証部４２３は、取引ｔｘに含まれる署名σと、元取引ｐｔｘに含まれる取引する相手先のグループの公開鍵ｐｋとを入力として、署名検証アルゴリズムを実行して、署名σの正当性を検証する。署名検証アルゴリズムとしては、非特許文献２に記載されたポリシーベース署名における署名検証アルゴリズムを用いることができる。つまり、図１５に示すように、署名検証部４２３は、取引ｔｘに含まれる署名σを元取引ｐｔｘに含まれる取引する相手先のグループの公開鍵ｐｋで検証する。署名検証部４２３は、署名σの正当性が確認できた場合には、検証成功を示す値“１”をメモリ３２に書き込み、署名σの正当性が確認できない場合には、検証失敗を示す値“０”をメモリ３２に書き込む。
　（ステップＳ４４：結果出力処理）
　結果出力部４２４は、ステップＳ４２又はステップＳ４３で行われた検証結果を出力する。
　具体的には、結果出力部４２４は、メモリ３２から検証結果である検証成功又は検証失敗を示す値を読み出す。そして、結果出力部４２４は、読み出された検証結果を、ステップＳ４１で取得された取引ｔｘと関連付けて取引記憶部３３１に書き込む。
　図１６と、図５及び図８とを参照して、実施の形態１に係るブロック生成部４３の動作であるブロック生成処理を説明する。
　ブロック生成処理は、１０分毎といった一定時間毎に、通信装置３０のブロック生成部４３によって実行される。
　（ステップＳ５１：取引収集処理）
　取引収集部４３１は、取引記憶部３３１から取引ｔｘの集合である取引集合ｔｘｓを読み出す。この際、取引収集部４３１は、取引記憶部３３１に記憶された複数の取引ｔｘのうち、検証結果が検証成功であり、かつ、過去のブロック生成処理で処理対象となっていない全ての取引ｔｘの集合を取引集合ｔｘｓとして読み出す。取引収集部４３１は、読み出された取引集合ｔｘｓをメモリ３２に書き込む。
　（ステップＳ５２：ブロック生成処理）
　ブロック生成部４３２は、ステップＳ５１で読み出された取引集合ｔｘｓからブロックｂｃを生成する。
　具体的には、ブロック生成部４３２は、メモリ３２から取引集合ｔｘｓを読み出す。ブロック生成部４３２は、読み出された取引集合ｔｘｓを入力としてコンセンサスアルゴリズムを実行して、ブロックｂｃを生成する。コンセンサスアルゴリズムとしては、非特許文献１に記載されたＰＲＯＯＦ　ＯＦ　ＷＯＲＫアルゴリズムを用いることができる。ブロック生成部４３２は、生成されたブロックｂｃをメモリ３２に書き込む。
　非特許文献１に記載されたＰＲＯＯＦ　ＯＦ　ＷＯＲＫアルゴリズムでは、ナンス値をランダムに計算し、読み出された取引集合ｔｘｓと、前回に実行されたブロック生成処理で生成されたブロックｂｃのハッシュ値とをハッシュ関数の入力としてハッシュ値が計算される。そして、計算されたハッシュ値が基準値以下になるまで、ナンス値を変更してハッシュ値を計算し直す。基準値以下のハッシュ値が計算されると、取引集合ｔｘｓと、前回に実行されたブロック生成処理で生成されたブロックｂｃのハッシュ値と、ナンス値とを合わせたものがブロックｂｃとされる。
　（ステップＳ５３：ブロック出力処理）
　ブロック出力部４３３は、ステップＳ５２で生成されたブロックｂｃを出力する。具体的には、ブロック出力部４３３は、メモリ３２からブロックｂｃを読み出して、通信インタフェース３４を介して、他の通信装置３０に送信する。他の通信装置３０には、同じグループに属する通信装置３０だけでなく、他のグループに属する通信装置３０も含まれる。
　図１７と、図５及び図９とを参照して、実施の形態１に係るブロック検証部４４の動作であるブロック検証処理を説明する。
　ブロック検証処理は、他の通信装置３０から新たなブロックｂｃが受信された場合に、通信装置３０のブロック検証部４４によって実行される。
　（ステップＳ６１：ブロック取得処理）
　ブロック取得部４４１は、ステップＳ５３で出力されたブロックｂｃを取得する。具体的には、ブロック取得部４４１は、ブロックｂｃを通信インタフェース１４を介して受信する。ブロック取得部４４１は、取得されたブロックｂｃをメモリ３２に書き込む。
　（ステップＳ６２：ブロック検証処理）
　ブロック検証部４４２は、ステップＳ６１で取得されたブロックｂｃの正当性を検証する。
　具体的には、ブロック検証部４４２は、メモリ３２からブロックｂｃを読み出す。ブロック検証部４４２は、読み出されたブロックｂｃを入力として、ステップＳ５２で用いられたコンセンサスアルゴリズムに対応する検証アルゴリズムを実行して、ブロックｂｃの正当性を検証する。検証アルゴリズムとしては、非特許文献１に記載されたＰＲＯＯＦ　ＯＦ　ＷＯＲＫアルゴリズムを用いることができる。ブロック検証部４４２は、ブロックｂｃの正当性が確認できた場合には、検証成功を示す値“１”をメモリ３２に書き込み、ブロックｂｃの正当性が確認できない場合には、検証失敗を示す値“０”をメモリ３２に書き込む。
　非特許文献１に記載されたＰＲＯＯＦ　ＯＦ　ＷＯＲＫアルゴリズムでは、ブロックｂｃをハッシュ関数の入力としてハッシュ値が計算される。計算されたハッシュ値が基準値以下である場合には、正当性が確認され、計算されたハッシュ値が基準値よりも大きい場合には、正当性が確認されない。
　（ステップＳ６３：結果出力処理）
　結果出力部４４３は、ステップＳ６２で正当性が確認された場合には、ステップ６１で取得されたブロックｂｃをブロック記憶部３３２に書き込む。一方、結果出力部４４３は、ステップＳ６２で正当性が確認されなかった場合には、ステップ６１で取得されたブロックｂｃを破棄する。
　具体的には、結果出力部４４３は、メモリ３２から検証結果である検証成功又は検証失敗を示す値を読み出す。結果出力部４４３は、読み出された検証結果が検証成功を示す場合には、メモリ３２からブロックｂｃを読み出して、ブロック記憶部３３２に書き込む。一方、結果出力部４４３は、読み出された検証結果が検証失敗を示す場合には、メモリ３２からブロックｂｃを削除する。
　＊＊＊実施の形態１の効果＊＊＊
　以上のように、実施の形態１に係る分散型元帳システム１では、グループ毎に公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアが生成される。そして、各グループにおいて、ユーザ毎にポリシーΓが決められ、ポリシーΓが設定されたユーザ秘密鍵ｓｋΓが生成される。これにより、複数のユーザからなるグループ間でのブロックチェーンによる取引におけるユーザ毎の権限を制御可能である。
　図１８を参照して具体例を説明する。
　従来であれば、経理部長から秘密鍵を渡された経理担当者は、任意の内容に対して署名を生成できる。そのため、経理担当者は、任意の内容の取引を行うことができる。例えば、Ｘ社へ１０億円の支払いといった高額の取引についても行うことができる。
　これに対して、実施の形態１に係る分散型元帳システム１では、経理部長はユーザ毎に署名対象を制限するポリシーΓを設定して、ユーザ秘密鍵ｓｋΓを生成できる。そのため、例えば、経理担当者に対して署名対象を“Ｘ社又はＹ社との１００万円以下の取引”に制限したユーザ秘密鍵ｓｋΓを生成することができる。この場合、経理担当者は、Ｘ社への１００万円の支払いという取引については、署名を生成することができるため、行うことができる。しかし、Ｂ社への２００万円の支払いという取引と、Ｃ社への１００万円の支払いという取引とについては、署名を生成することができないため、行うことができない。
　また、実施の形態１に係る分散型元帳システム１では、取引の相手先は、署名を検証することによって、グループに属するユーザが署名を生成したことを確認することはできる。しかし、取引の相手先は、グループに属するユーザのうち、どのユーザが署名を生成したかは確認することができない。その結果、どのユーザがどのグループに属しているといった情報が他のグループに漏えいすることがない。
　また、実施の形態１に係る分散型元帳システム１では、複数のユーザからなるグループを相手先として取引を行う場合にも１つの署名を生成するだけでよい。つまり、従来のように、相手先とするユーザ毎に署名を生成する必要はない。そのため、署名生成の時間を短縮することが可能である。
　同様に、相手先のグループの公開鍵だけを取引に含めればよく、相手先とする各ユーザの公開鍵を取引に含める必要はない。そのため、公開鍵を取得する手間がかからない。また、取引のデータサイズを小さくすることができる。
　＊＊＊他の構成＊＊＊
　＜変形例１＞
　実施の形態１では、分散型元帳システム１は、グループ毎に鍵生成装置１０を備えた。しかし、図１９に示すように、分散型元帳システム１は、各グループに共通の鍵生成装置１０を備えてもよい。この場合、鍵生成装置１０は、グループ毎に別々の公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを生成する。そして、鍵生成装置１０は、ユーザが属するグループのマスター秘密鍵ｍｓｋを用いて、ユーザ秘密鍵ｓｋΓを生成する。
　＜変形例２＞
　実施の形態１では、鍵生成装置１０は、マスター鍵生成部２１とユーザ鍵生成部２２とを備えた。しかし、マスター鍵生成部２１とユーザ鍵生成部２２とを別の装置が備える構成としてもよい。
　実施の形態１では、通信装置３０は、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４とを備えた。しかし、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４とを別の装置が備える構成としてもよい。
　例えば、通信装置３０Ｘは、取引生成部４１と取引検証部４２とのみを備え、通信装置３０Ｙは、ブロック生成部４３とブロック検証部４４とのみを備えてもよい。また、通信装置３０Ｘ及び通信装置３０Ｙと同じグループに属する通信装置３０Ｚは、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４とを備えてもよい。
　＜変形例３＞
　実施の形態１では、鍵生成装置１０のマスター鍵生成部２１とユーザ鍵生成部２２との機能がソフトウェアで実現された。また、通信装置３０の取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能がソフトウェアで実現された。しかし、変形例３として、鍵生成装置１０のマスター鍵生成部２１とユーザ鍵生成部２２との機能と、通信装置３０の取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能とはハードウェアで実現されてもよい。この変形例３について、実施の形態１と異なる点を説明する。
　図２０を参照して、変形例３に係る鍵生成装置１０の構成を説明する。
　マスター鍵生成部２１とユーザ鍵生成部２２との機能がハードウェアで実現される場合、鍵生成装置１０は、プロセッサ１１に代えて、処理回路１５を備える。処理回路１５は、マスター鍵生成部２１とユーザ鍵生成部２２との機能を実現する専用の電子回路である。
　図２１を参照して、変形例３に係る通信装置３０の構成を説明する。
　取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能がハードウェアで実現される場合、通信装置３０は、プロセッサ３１に代えて、処理回路３５を備える。処理回路３５は、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能を実現する専用の電子回路である。
　処理回路１５，３５は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ　Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）が想定される。
　マスター鍵生成部２１とユーザ鍵生成部２２との機能を１つの処理回路１５で実現してもよいし、マスター鍵生成部２１とユーザ鍵生成部２２との機能を複数の処理回路１５に分散させて実現してもよい。同様に、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能を１つの処理回路３５で実現してもよいし、取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４との機能を複数の処理回路３５に分散させて実現してもよい。
　＜変形例４＞
　変形例４として、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。つまり、マスター鍵生成部２１とユーザ鍵生成部２２と取引生成部４１と取引検証部４２とブロック生成部４３とブロック検証部４４とのうち、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。
　プロセッサ１１，３１とメモリ１２，３２とストレージ１３，３３と処理回路１５，３５とを、総称して「プロセッシングサーキットリー」という。つまり、各機能構成要素の機能は、プロセッシングサーキットリーにより実現される。
　実施の形態２．
　実施の形態２では、署名方式として、ポリシーベース署名の特殊系である属性ベース署名を用いる点が実施の形態１と異なる。実施の形態２では、この異なる点を説明し、同一の点については説明を省略する。
　＊＊＊動作の説明＊＊＊
　図１０から図１２と、図１４と、図２２から図２３とを参照して、実施の形態２に係る分散型元帳システム１の動作を説明する。
　実施の形態２に係る分散型元帳システム１における鍵生成装置１０の動作は、実施の形態２に係る鍵生成方法に相当する。また、実施の形態２に係る分散型元帳システム１における鍵生成装置１０の動作は、実施の形態２に係る鍵生成プログラムの処理に相当する。
　実施の形態２に係る分散型元帳システム１における通信装置３０の動作は、実施の形態２に係る通信方法に相当する。また、実施の形態２に係る分散型元帳システム１における通信装置３０の動作は、実施の形態２に係る通信プログラムの処理に相当する。
　実施の形態２では、署名方式として、属性ベース署名を用いる。属性ベース署名では、ユーザ秘密鍵ｓｋΓにポリシーΓとしてユーザの属性情報が設定されており、署名対象のデータに署名者に必要な属性条件を示す論理式が含まれている。そして、属性ベース署名では、属性情報が論理式が示す属性条件を満たす場合にのみ正しい署名を生成することが可能である。
　図１０を参照して、実施の形態２に係るマスター鍵生成部２１の動作であるマスター鍵生成処理を説明する。
　ステップＳ１１とステップＳ１３との処理は、実施の形態１と同じである。
　（ステップＳ１２：マスター鍵生成処理）
　鍵生成部２１２は、属性ベース署名におけるマスター鍵生成アルゴリズムを実行して、公開鍵ｐｋとマスター秘密鍵ｍｓｋとのペアを生成する。属性ベース署名におけるマスター鍵生成アルゴリズムとしては、特許文献１に記載されたマスター鍵生成アルゴリズムを用いることができる。
　図１１を参照して、実施の形態２に係るユーザ鍵生成部２２の動作であるユーザ鍵生成処理を説明する。
　ステップＳ２１とステップＳ２４との処理は、実施の形態１と同じである。
　（ステップＳ２２：ポリシー受付処理）
　ポリシー受付部２２２は、ポリシーΓを受け付ける。
　ポリシーΓは、ユーザ秘密鍵ｓｋΓを使用するユーザの属性情報である。具体例としては、ポリシーΓは、ユーザの所属先と、性別と、年齢と、住所といった情報である。
　（ステップＳ２３：ユーザ秘密鍵生成処理）
　鍵生成部２２３は、属性ベース署名におけるユーザ秘密鍵生成アルゴリズムを実行して、ポリシーΓである属性情報が設定されたユーザ秘密鍵ｓｋΓを生成する。属性ベース署名におけるユーザ秘密鍵生成アルゴリズムとしては、特許文献１に記載されたユーザ秘密鍵生成アルゴリズムを用いることができる。
　図１２を参照して、実施の形態２に係る取引生成部４１の動作である取引生成処理を説明する。
　ステップＳ３１とステップＳ３４との処理は、実施の形態１と同じである。
　（ステップＳ３２：内容受付処理）
　内容受付部４１２は、取引内容ｔｘｃを受け付ける。
　図２２に示すように、取引内容ｔｘｃに含まれる取引情報は、実施の形態１における取引内容ｔｘｃに加えて、署名者が満たす論理式と、次取引者が満たす論理式とを含む。署名者が満たす論理式は、ユーザが取引情報に対して正しい署名を生成するために必要な属性条件を示す。図２３に示すように、署名者が満たす論理式には、元識別子が示す元取引ｐｔｘに含まれる次取引者が満たす論理式が設定される。次取引者が満たす論理式は、取引内容ｔｘｃを含む取引ｔｘを元取引とした新たな取引を行うユーザが正しい署名を生成するために必要な属性条件を示す。
　具体例としては、署名者が満たす論理式は、“Ｘ社　ＡＮＤ　経理部”であり、次取引者が満たす論理式は、“Ｙ社　ＡＮＤ　総務部”である。この場合、取引ｔｘを元取引とした新たな取引における署名者が満たす論理式は、“Ｙ社　ＡＮＤ　総務部”になる。
　ステップＳ３３では、署名生成部４１３は、属性ベース署名における署名生成アルゴリズムを実行することにより、署名σを生成する。属性ベース署名における署名生成アルゴリズムとしては、特許文献１に記載された署名生成アルゴリズムを用いることができる。
　属性ベース署名では、ユーザ秘密鍵ｓｋΓに設定された属性情報が、取引情報に含まれる署名者が満たす論理式が示す属性条件を満たす場合にのみ正しい署名を生成することが可能である。つまり、署名者が満たす論理式が“Ｘ社　ＡＮＤ　経理部”である場合、“Ｘ社　ＡＮＤ　経理部”を満たす属性情報が設定されたユーザ秘密鍵ｓｋΓでのみ、取引ｔｘに正しい署名を生成することが可能になる。
　図１４を参照して、実施の形態２に係る取引検証部４２の動作である取引検証処理を説明する。
　ステップＳ４１からステップＳ４２とステップＳ４４との処理は、実施の形態１と同じである。
　（ステップＳ４３：署名検証処理）
　署名検証部４２３は、属性ベース署名における署名検証アルゴリズムを実行して、署名σの正当性を検証する。属性ベース署名における署名検証アルゴリズムとしては、特許文献１に記載された署名検証アルゴリズムを用いることができる。
　＊＊＊実施の形態２の効果＊＊＊
　以上のように、実施の形態２に係る分散型元帳システム１では、属性ベース署名が用いられ、署名者が満たす論理式と次取引者が満たす論理式とが取引内容ｔｘｃに含まれる。そして、取引内容ｔｘｃを含む取引ｔｘを元取引とした新たな取引では、次取引者が満たす論理式が、署名者が満たす論理式になる。これにより、相手先のグループにおける担当者を指定した取引を行うことが可能である。
　例えば、次取引者が満たす論理式を“Ｙ社　ＡＮＤ　総務部”とすることにより、相手先のグループである会社Ｙに属するユーザのうち、総務部に属するユーザを担当者として指定することが可能である。
　なお、特許文献１に記載された属性ベース署名アルゴリズムでは、取引の相手先は、署名を検証することによって、署名者が満たす論理式を満たしたユーザによって署名がされたことを確認することはできる。しかし、取引の相手先は、署名を生成したユーザの属性情報を特定することはできない。
　図２４を参照して、具体例を説明する。
　署名者が満たす論理式が“Ｘ社　ＡＮＤ　（Ｌ部　ＯＲ　Ｍ部）”であり、次取引者が満たす論理式が“Ｙ社　ＡＮＤ　Ｎ部　ＡＮＤ　課長以上”である取引を、Ｘ社のＬ部の課長であるユーザＺが行ったとする。Ｙ社におけるＮ部の課長以上の役職を有する、Ｎ部の部長及びＮ部の課長は、この取引を扱うことができる。一方、Ｙ社におけるＰ部の部長は、この取引を扱うことができない。この取引を扱うとは、この取引を元取引として新たな取引を行うことである。
　また、Ｎ部の部長及びＮ部の課長は、この取引に含まれる署名を検証することで、“Ｘ社　ＡＮＤ　（Ｌ部　ＯＲ　Ｍ部）”を満たす属性を有するユーザによって署名が生成されたことを確認できるが、ユーザＺによって署名が生成されたこと、及び、ユーザＺが課長であることを特定することはできない。
　１　分散型元帳システム、１０　鍵生成装置、１１　プロセッサ、１２　メモリ、１３　ストレージ、１３１　マスター鍵記憶部、１３２　ユーザ鍵記憶部、１４　通信インタフェース、１５　処理回路、２１　マスター鍵生成部、２１１　セキュリティパラメータ受付部、２１２　鍵生成部、２１３　鍵出力部、２２　ユーザ鍵生成部、２２１　マスター鍵取得部、２２２　ポリシー受付部、２２３　鍵生成部、２２４　鍵出力部、３０　通信装置、３１　プロセッサ、３２　メモリ、３３　ストレージ、３３１　取引記憶部、３３２　ブロック記憶部、３４　通信インタフェース、３５　処理回路、４１　取引生成部、４１１　ユーザ鍵取得部、４１２　内容受付部、４１３　署名生成部、４１４　取引出力部、４２　取引検証部、４２１　取引取得部、４２２　内容検証部、４２３　署名検証部、４２４　結果出力部、４３　ブロック生成部、４３１　取引収集部、４３２　ブロック生成部、４３３　ブロック出力部、４４　ブロック検証部、４４１　ブロック取得部、４４２　ブロック検証部、４４３　結果出力部、５０　ネットワーク、λ　セキュリティパラメータ、Γ　ポリシー、ｐｋ　公開鍵、ｍｓｋ　マスター秘密鍵、ｓｋΓ　ユーザ秘密鍵、ｔｘｃ　取引内容、ｔｘ　取引、ｐｔｘ　元取引、ｔｘｓ　取引集合、ｂｃ　ブロック、σ　署名。

Claims (8)

  1. 　他のグループに属する通信装置から出力された取引を取得する取引取得部と、
    　属するグループにおける公開鍵と対を成すマスター秘密鍵と、署名対象を制限するポリシーとに基づき生成されたユーザ秘密鍵を用いて、取引する内容と、送信先のグループの公開鍵とを含む取引情報に対して署名を生成する署名生成部と、
    　前記取引取得部によって取得された前記取引を特定可能な元識別子と、前記取引情報と、前記署名生成部によって生成された署名とを含む新たな取引を出力する取引出力部と
    を備える通信装置。
  2. 　前記署名生成部は、前記取引情報が前記ポリシーの署名対象である場合に、前記署名を生成する
    請求項１に記載の通信装置。
  3. 　前記ポリシーは、属性情報であり、
    　前記取引情報は、署名者に必要な属性条件を示す論理式を含み、
    　前記署名生成部は、前記論理式が示す属性条件を前記属性情報が満たす場合に、前記署名を生成する
    請求項２に記載の通信装置。
  4. 　前記取引出力部は、次取引者に必要な属性条件を示す論理式を含む前記新たな取引を出力する
    請求項３に記載の通信装置。
  5. 　前記取引取得部は、次取引者に必要な属性条件を示す論理式を含む前記取引を取得し、
    　前記取引情報は、前記取引取得部によって取得された前記取引に含まれる、前記次取引者に必要な属性条件を示す論理式を、前記署名者に必要な属性条件を示す論理式として含む
    請求項３又は４に記載の通信装置。
  6. 　前記取引出力部は、前記取引取得部によって取得された取引のうち、前記取引情報が前記属するグループにおける公開鍵を含む取引を特定可能な元識別子を含む前記新たな取引を出力する
    請求項１に記載の通信装置。
  7. 　複数のグループそれぞれに属する通信装置を備える分散型元帳システムであり、
    　前記複数のグループのうちの送信元のグループに属する通信装置は、
    　他のグループに属する通信装置から出力された取引を取得する取引取得部と、
    　前記送信元のグループにおける公開鍵と対を成すマスター秘密鍵と、署名対象を制限するポリシーとに基づき生成されたユーザ秘密鍵を用いて、取引する内容と、前記複数のグループのうちの送信先のグループの公開鍵とを含む取引情報に対して署名を生成する署名生成部と、
    　前記取引取得部によって取得された前記取引を特定可能な元識別子と、前記取引情報と、前記署名生成部によって生成された署名とを含む新たな取引を出力する取引出力部と
    を備え、
    　前記送信先のグループに属する通信装置は、
    　前記送信元のグループの公開鍵により、前記取引出力部によって出力された前記新たな取引に含まれる署名を検証する署名検証部
    を備える分散型元帳システム。
  8. 　前記分散型元帳システムは、さらに、
    　前記複数のグループそれぞれについて別々に、公開鍵と、前記公開鍵と対を成すマスター秘密鍵を生成するとともに、前記複数のグループそれぞれに属するユーザに対して、生成されたマスター秘密鍵と署名対象を制限するポリシーとに基づきユーザ秘密鍵を生成する鍵生成装置
    を備える請求項７に記載の分散型元帳システム。
PCT/JP2016/086244 2016-12-06 2016-12-06 通信装置及び分散型元帳システム WO2018105038A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/086244 WO2018105038A1 (ja) 2016-12-06 2016-12-06 通信装置及び分散型元帳システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/086244 WO2018105038A1 (ja) 2016-12-06 2016-12-06 通信装置及び分散型元帳システム

Publications (1)

Publication Number Publication Date
WO2018105038A1 true WO2018105038A1 (ja) 2018-06-14

Family

ID=62490926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/086244 WO2018105038A1 (ja) 2016-12-06 2016-12-06 通信装置及び分散型元帳システム

Country Status (1)

Country Link
WO (1) WO2018105038A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020024994A1 (zh) * 2018-07-31 2020-02-06 杭州复杂美科技有限公司 一种隐私交易方法及系统、设备和可存储介质
WO2020024996A1 (zh) * 2018-07-31 2020-02-06 杭州复杂美科技有限公司 一种隐私交易方法及系统、设备和可存储介质
JP2020170342A (ja) * 2019-04-03 2020-10-15 株式会社日立製作所 分散台帳装置、分散台帳システム、及び分散台帳管理方法
CN112913185A (zh) * 2018-07-27 2021-06-04 朴琪业 在区块链网络上构建基于组密钥的双重签名交易结构的节点组管理装置以及计算装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150324787A1 (en) * 2014-05-08 2015-11-12 Sequitur Labs, Inc. Policy-Based Control and Augmentation of Cryptocurrencies and Cryptocurrency Security

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150324787A1 (en) * 2014-05-08 2015-11-12 Sequitur Labs, Inc. Policy-Based Control and Augmentation of Cryptocurrencies and Cryptocurrency Security

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HITESH TEWARI ET AL.: "Netcoin: A Traceable P2P Electronic Cash System", 2015 IEEE INTERNATIONAL CONFERENCE ON WEB SERVICES, 19 June 2015 (2015-06-19), pages 472 - 478, XP061018753 *
RYO SHIMAMURA, 5 FUN DE WAKARU BLOCK CHAIN NO KIHONTEKI NA SHIKUMI, 17 February 2016 (2016-02-17), pages 2 - 45, Retrieved from the Internet <URL:http://www.slideshare.net/cookle/5-58379474> [retrieved on 20170105] *
TATUAKI OKAMOTO ET AL.: "Decentralized Attribute-Based Signatures", PKC 2013- 16TH INTERNATIONAL CONFERENCE ON PRACTICE AND THEORY IN PUBLIC-KEY CRYPTOGRAPHY, vol. 7778, 26 February 2013 (2013-02-26), pages 125 - 142, XP055512185, Retrieved from the Internet <URL:https://www.iacr.org/archive/pkc2013/77780125/77780125.pdf> [retrieved on 20170105] *
TOSHIHIRO OHIGASHI ET AL.: "Implementation and Evaluation of a File Sharing Service with File Name Encryption Using Ciphertext-policy Attribute-based Encryption", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 55, no. 3, 15 March 2014 (2014-03-15), pages 1126 - 1139 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112913185A (zh) * 2018-07-27 2021-06-04 朴琪业 在区块链网络上构建基于组密钥的双重签名交易结构的节点组管理装置以及计算装置
JP2021533638A (ja) * 2018-07-27 2021-12-02 バク ギオブPARK, Ki Eob ブロックチェーンネットワーク上でグループ鍵基盤の二重署名トランザクション構造を構成するノードグループ管理装置およびコンピューティング装置
WO2020024994A1 (zh) * 2018-07-31 2020-02-06 杭州复杂美科技有限公司 一种隐私交易方法及系统、设备和可存储介质
WO2020024996A1 (zh) * 2018-07-31 2020-02-06 杭州复杂美科技有限公司 一种隐私交易方法及系统、设备和可存储介质
JP2020170342A (ja) * 2019-04-03 2020-10-15 株式会社日立製作所 分散台帳装置、分散台帳システム、及び分散台帳管理方法
US11483158B2 (en) * 2019-04-03 2022-10-25 Hitachi, Ltd. Distributed ledger device, distributed ledger system, and distributed ledger management method
JP7316081B2 (ja) 2019-04-03 2023-07-27 株式会社日立製作所 分散台帳装置、分散台帳システム、及び分散台帳管理方法

Similar Documents

Publication Publication Date Title
US11341492B2 (en) Method, apparatus and electronic device for blockchain transactions
WO2018137316A1 (zh) 基于区块链的安全交易方法、电子装置、系统及存储介质
JP2020528224A (ja) 信頼できる実行環境におけるスマート契約動作のセキュアな実行
WO2019137566A2 (en) Methods and devices for validating transaction in blockchain system
CN111801910A (zh) 基于证明验证的用于认证链外数据的系统和方法
US11354657B2 (en) Managing transactions in multiple blockchain networks
US20210344500A1 (en) Computer-implemented system and method for transferring access to digital resource
US11372848B2 (en) Managing transactions in multiple blockchain networks
WO2021204273A1 (zh) 资产类型注册、交易记录验证
WO2018105038A1 (ja) 通信装置及び分散型元帳システム
WO2021134900A1 (zh) 区块链供应链交易隐藏静态监管系统及方法
CN112435026B (zh) 用零知识证明保护文件交易信息的方法、装置和电子设备
US20220141021A1 (en) Methods, systems, and devices for concealing account balances in ledgers
CN113065934B (zh) 一种隐私可验证的竞拍方法、系统、计算机设备及应用
JP2020078081A (ja) ブロックチェーン機密トランザクションの管理
US11403632B2 (en) Managing transactions in multiple blockchain networks
US20230237437A1 (en) Apparatuses and methods for determining and processing dormant user data in a job resume immutable sequential listing
JP2021064891A (ja) コンソーシアムブロックチェーンシステム、計算機、トランザクション承認方法
WO2021114495A1 (zh) 基于区块链的供应链交易隐私保护系统、方法及相关设备
JP7364238B2 (ja) 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム
CN108259180B (zh) 一种量子指定验证者签名的方法
US20230316241A1 (en) Partitioning a request into transactions for a blockchain
WO2013153628A1 (ja) 演算処理システムおよび演算結果認証方法
WO2022089518A1 (zh) 地址的生成方法、区块链信息的处理方法以及相关设备
CN114846765B (zh) 提供去中心化身份验证的方法和设备

Legal Events

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

Ref document number: 16923475

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16923475

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP