WO2019082442A1 - データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム - Google Patents

データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム

Info

Publication number
WO2019082442A1
WO2019082442A1 PCT/JP2018/024401 JP2018024401W WO2019082442A1 WO 2019082442 A1 WO2019082442 A1 WO 2019082442A1 JP 2018024401 W JP2018024401 W JP 2018024401W WO 2019082442 A1 WO2019082442 A1 WO 2019082442A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
common key
key
encrypted
item
Prior art date
Application number
PCT/JP2018/024401
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 EP18870135.3A priority Critical patent/EP3703306A4/en
Priority to JP2019549840A priority patent/JP7235668B2/ja
Priority to US16/757,736 priority patent/US11720689B2/en
Publication of WO2019082442A1 publication Critical patent/WO2019082442A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0861—Generation of secret information including derivation or calculation 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates to a data registration method, a data decryption method, a data structure, a computer, and a program.
  • Non-Patent Document 1 In the above-mentioned virtual currency, the transaction is limited to the transaction record of the currency such as "who passed from who to whom".
  • the user himself can set the information to be recorded by the transaction and script code in a programmable manner. Therefore, it becomes easy to apply the block chain to various uses other than currency trading such as stock trading, insurance business, and copyright management.
  • These basic technologies are called smart contract blockchains because they obtain agreement among participants regarding a certain contract.
  • the user can set contract items in a programmable manner as in a smart contract type block chain, it is required to design concealment more flexibly.
  • a smart contract-type block chain to trading of a freight insurance policy in the trade business, it is possible to set an item to be concealed flexibly in a plurality of items, and to make a plurality of different such as insurance company, notification bank, issuing bank
  • the scope of disclosure can be set in combination between organizations.
  • management information such as which item is encrypted among contract data having a plurality of items, which user is disclosed only to which user, and which key is used for decryption is complicated. .
  • the procedure of key exchange required to obtain the common key and the management of the public key and the secret key become complicated, which causes a heavy operation burden on the user.
  • Non-Patent Document 2 it is conceivable to cope with such a problem by providing a centrally managed concealment server outside the block chain system.
  • Management information for concealment is stored inside the concealment server, and an encryption / decryption function is provided according to the request of the user.
  • the concealed information is included in the contract data and stored in the distributed ledger in the block chain system.
  • the encryption server manages the items of encryption and the disclosure range. This reduces the burden on the user.
  • the distributive nature of authority which is a feature of the block chain system is impaired. For example, it is difficult to prevent an internal fraud that an administrator of the concealment server abuses the authority and looks into confidential information stored by other companies.
  • the object of the present invention made in view of this point is that a part of data registered in the dispersion register without the user being bothered with complicated procedures or managing keys without placing a centralized concealment server.
  • the present invention is to provide a data registration method, data decoding method, data structure, computer, and program capable of flexibly concealing and managing data.
  • a data registration method in a computer includes the steps of generating a common key for encrypting and decrypting an item included in data registered in the dispersion register, and an access right to the item Obtaining a public key for each account of the user having the key, encrypting the common key with each public key for each account, and transmitting each common key encrypted for each account via a transaction And d) registering in the distribution register.
  • a data decryption method in a computer includes the steps of acquiring data including encrypted items registered in the distribution ledger via a transaction; Obtaining confidential management information registered in the dispersion register; and the encrypted item and the encrypted common key for decrypting the encrypted item from the confidential management information; Obtaining the encrypted item, decrypting the encrypted common key with a secret key corresponding to the common key, and decrypting the encrypted item using the decrypted common key. And decrypting.
  • the data structure of the secret management information of the present embodiment is the account information of the user who has the access right to the encrypted item of the data registered in the dispersion register via the transaction, Information indicating an encrypted item, information on a public key used to encrypt a common key for decrypting the encrypted item, and the common key encrypted by the public key ,including.
  • the account information specifies which user the secret management information corresponds to.
  • the common key is decrypted using a secret key corresponding to the public key.
  • the decrypted common key is used to decrypt the encrypted item.
  • the computer generates a common key for encrypting and decrypting an item included in data registered in the dispersion register, and a user having an access right to the item
  • a processor for obtaining a public key for each account, encrypting the common key with each public key for each account, and registering each common key encrypted for each account in the distribution ledger through a transaction Equipped with
  • the program according to the present embodiment generates, in the computer, a common key for encrypting and decrypting an item included in data registered in the distribution register, and an access to the item
  • the user is not bothered with complicated procedures or management of keys without placing a centralized concealment server. , It is possible to flexibly conceal and manage a part of data registered in the dispersion register.
  • FIG. 1 is a functional block diagram showing the concealment system S of the present embodiment.
  • the concealment system S of this embodiment includes a network NW, verification terminals 1A, 1B and 1C, intermediate servers 2A, 2B and 2C, user terminals 3A, 3B, 3C, 3X, 3Y, 3Z, 3S, 3T and And 3U.
  • the network NW of this embodiment is a block chain network.
  • Verification terminals 1A, 1B and 1C of this embodiment are block chain verification terminals.
  • the user terminals 3A, 3B and 3C are provided in the organization 1, the user terminals 3X, 3Y and 3Z are provided in the organization 2, and the user terminals 3S, 3T and 3U are provided in the organization 3.
  • the organization is, for example, an insurance company, a bank or the like.
  • the user terminals 3A, 3B and 3C connect to the verification terminal 1A via the intermediate server 2A.
  • the user terminals 3X, 3Y and 3Z connect to the verification terminal 1B via the intermediate server 2B.
  • the user terminals 3S, 3T, and 3U connect to the verification terminal 1C via the intermediate server 2C.
  • the processing executed by the verification terminal 1A, the intermediate server 2A and the user terminals 3A, 3B and 3C will be mainly described.
  • the explanation also applies to the verification terminal 1B, the intermediate server 2B and the user terminals 3X, 3Y and 3Z, and also to the verification terminal 1C, the intermediate server 2C and the user terminals 3S, 3T and 3U.
  • the verification terminal 1A incorporates software having basic functions for using the block chain system, such as transaction verification or propagation, recording or reference to the dispersion ledger 12A (see FIG. 3) described later.
  • the verification terminal 1A may not be a dedicated software for using the concealment system S, and may use a general-purpose block chain basis such as Ethereum or Hyperledger Fabric.
  • the intermediate server 2A receives a request from each user terminal connected to the intermediate server 2A, communicates with the verification terminal 1A, and executes a designated process.
  • Each intermediate server is distributed and operated in organizational units to which the management authority is divided.
  • One intermediate server is assigned to one verification terminal. Multiple user terminals in the same organization may be connected to one intermediate server. However, an intermediate server connected to a user terminal of one organization is not directly connected to a user terminal of another organization.
  • the verification terminal 1A and the intermediate server 2A do not necessarily have to be physically separated, and may be implemented on the same physical terminal using virtualization or the like.
  • the verification terminals 1A, 1B and 1C are connected to one another via the network NW.
  • the number is not limited.
  • three user terminals are connected to each of the intermediate servers 2A, 2B and 2C in the example shown in FIG. 1, the number is not limited.
  • each function of the concealment system S of this embodiment will be described below, it is not intended to exclude other functions of the concealment system S.
  • FIG. 2A shows an example of structured contract data used in the present embodiment.
  • the contract data is data on a contract exchanged by a plurality of persons. Contract data is generated at the user terminal by user input. A part of the contract data is not disclosed to the whole of the concealing system S, and is encrypted (hiddenized) by a method described later and recorded in the distributed ledger 12A. After performing the encryption, as shown in the range R21 and the range R22 of FIG. 2B, some items (“contractors”, “amount” and “charges”) of the contract data are encrypted.
  • the data registered in the dispersion ledger 12A is not limited to the contract data, and any other data may be registered.
  • the key for decryption is shared by the concealment system S only to the designated user terminal.
  • Each intermediate server performs decryption automatically. For this reason, each user terminal does not display the ciphertext as shown in FIG. 2B. Therefore, the user does not directly see the ciphertext as shown in FIG. 2B.
  • Each user terminal displays a plaintext as shown in FIG. 2A.
  • FIG. 3 is a functional block diagram of the verification terminal 1A.
  • the verification terminal 1A includes a control unit 11 and a storage unit 12.
  • the hardware configuration of the verification terminals 1B and 1C is the same as that of the verification terminal 1A, so the description will be omitted.
  • the control unit 11 includes one or more processors.
  • a processor may include one or more memories that store programs for various processes and information in operations.
  • the memory includes volatile memory and non-volatile memory.
  • the memory includes a memory independent of the processor, and a built-in memory of the processor.
  • the processor includes a general purpose processor that loads a specific program to execute a specific function, and a dedicated processor specialized for a specific process.
  • the dedicated processor includes an application specific integrated circuit (ASIC).
  • the processor includes a programmable logic device (PLD).
  • the PLD includes an FPGA (Field-Programmable Gate Array).
  • the control unit 11 may be one of a SoC (System-on-a-Chip) in which one or more processors cooperate, and a SiP (System In a Package).
  • the control unit 11 has a contract data storage function 11A and a secret management function 11B.
  • the contract data storage function 11A and the secret management function 11B are implemented by script code.
  • the script code is stored in the storage unit 12.
  • the script code is, for example, a distributed executable program called "chain code” in Hyperledger Fabric based on a block chain based on a smart contract type, or "contract” in Ethereum.
  • script code may be stored inside the distributed ledger 12A.
  • the smart contract type block chain system executes this script code in accordance with the transaction issued by the user terminal, and makes an agreement with the verification terminal 1B or 1C of another organization about the execution result.
  • the key-value type data and the agreement result, which are the execution results, are recorded in the dispersion ledger 12A held in the verification terminal 1A.
  • the storage unit 12 is configured of a semiconductor memory, a magnetic memory, or the like.
  • the storage unit 12 includes a DB that stores arbitrary information such as a log, a program, and content.
  • the storage unit 12 may also function as a work memory.
  • the state DB 12A2 in the dispersion ledger 12A stored in the storage unit 12 stores data represented in a key-value type.
  • the block chain specific chained data store 12A1 stores a snapshot (such as a hash value) of the state DB 12A2 including the execution result of the script code.
  • the verification terminal 1A executes script code shown as the contract data storage function 11A and the secret management function 11B according to the protocol of the block chain to be used.
  • the contract data storage function 11A receives the transaction including the contract data from the intermediate server 2A, and records the transaction in the distribution ledger 12A in accordance with the block chain protocol.
  • the contract data is encrypted (hidden) by the intermediate server 2A when it includes the item to be encrypted. Therefore, the contract data received by the contract data storage function 11A is partially encrypted as shown in FIG. 2B. Since the ciphertext is treated as a string, a flag may be added to explicitly indicate that it is encrypted.
  • the concealment management function 11B receives a transaction including information necessary for concealment from the intermediate server 2A, and registers the transaction as the concealment management information in the dispersion ledger 12A according to the block chain protocol.
  • the secret management information as illustrated in FIG. 4, for account information of each user who has access authority to the encrypted item, public key information (refer to range R41) used for key exchange and contract data Information (see range R42) indicating which item is encrypted and common key (encrypted with the public key) information (see range R43) for the encrypted item are associated with each other.
  • the account indicates an ID that uniquely identifies the user. For example, in the example shown in FIG.
  • the secret management information may include identity information (see range R44) identifying an account (for example, a certificate issued by a CA (Certificate Authority) or a hash of a public key for signature verification).
  • the verification terminal 1A can verify whether the transaction has been issued by the account by collating the account with the identity information. For this reason, the verification terminal 1A can prevent unauthorized writing on the secret management information by an unauthorized user.
  • FIG. 5 shows a functional block diagram of the intermediate server 2A.
  • the hardware configuration of the intermediate servers 2B and 2C is the same as that of the intermediate server 2A, so the description will be omitted.
  • the intermediate server 2A includes a verification terminal cooperation unit 21, a key generation unit 22, a contract data processing unit 23, a key registration unit 24, and an encryption / decryption processing unit 25. These functional units are executed by the processor of the intermediate server 2A.
  • the verification terminal cooperation unit 21 has a transaction transmission function 21A, a dispersion ledger reference function 21B, and a signature key storage DB 21C.
  • the transaction transmission function 21A receives information from each functional unit, generates a transaction necessary for recording in the dispersion ledger 12A, and transmits it to the verification terminal 1A. Generation of transactions in the block chain system requires a digital signature key associated with each account.
  • the electronic signature key is stored in the signature key storage DB 21C.
  • the dispersion ledger reference function 21B has a function of referring to the dispersion ledger 12A held by the verification terminal 1A, and acquires contract data or concealment management information on the dispersion ledger 12A in response to a request from each functional unit.
  • the key generation unit 22 has a public key / secret key generation function 22A and a common key generation function 22B.
  • the public key / private key generation function 22A generates a public key and / or a private key in response to a request from another functional unit.
  • the public key / private key generation function 22A of this embodiment generates a pair of a public key and a private key for each account of the user.
  • the public key / private key generation function 22A can periodically update the public key / private key pair.
  • the intermediate server 2A re-registers the updated pair of the public key and the secret key in the distribution ledger 12A as secrecy management information.
  • the public key-private key pair is used to perform key exchange when sharing a common key.
  • the public key / private key generation function 22A uses, for example, the RSA public key cryptosystem to generate a public key and a private key.
  • the public key / private key generation function 22A passes the generated key pair to the key registration unit 24.
  • the common key generation function 22 B causes the encryption / decryption processing unit 25 to generate a common key used for encrypting or decrypting the item of the contract data.
  • a common key encryption method such as AES-GCM is used. That is, in this embodiment, the keys used for encryption and decryption are the same.
  • the key is hereinafter referred to as a common key.
  • the common key generation function 22B of the present embodiment generates a common key for each encryption target item included in the data. For example, when only the user terminal 3A, the user terminal 3X, and the user terminal 3S can refer to the item A, the common key generation function 22B generates a common key for the item A.
  • the common key generation function 22B encrypts the common key with the public key of the user terminal 3A, encrypts the common key with the public key of the user terminal 3X, and encrypts the common key with the public key of the user terminal 3S.
  • the item A is an item corresponding to the common key.
  • the contract data processing unit 23 has a contract data registration function 23A and a contract data acquisition function 23B.
  • the contract data registration function 23A requests the encryption / decryption processing unit 25 to encrypt when it is designated to encrypt a part of items of the contract data.
  • the contract data registration function 23A transmits the contract data to the verification terminal cooperation unit 21 after the encryption is performed.
  • the contract data is issued as a transaction via the verification terminal cooperation unit 21 and is recorded in the dispersion ledger 12A according to the process of the block chain system. That is, the contract data registration function 23A registers the contract data in the distributed ledger 12A via a transaction.
  • the contract data acquisition function 23 B requests the encryption / decryption processing unit 25 to decrypt when there is an encrypted item in part of the acquired contract data.
  • the contract data acquisition function 23B transmits the contract data to the request source terminal.
  • the key registration unit 24 has a public key registration function 24A, a secret key storage function 24B, and a secret key storage DB 24C.
  • the public key registration function 24A registers the public key generated by the key generation unit 22 in the dispersion ledger 12A via the verification terminal 1A. At this time, the public key is registered via a transaction.
  • the secret key storage function 24B registers the secret key generated by the key generation unit 22 in the secret key storage DB 24C in the intermediate server 2A so as not to leak it to the outside.
  • the encryption / decryption processing unit 25 executes encryption or decryption processing on the item for which encryption or decryption is requested in response to the request from the contract data processing unit 23, and the contract data processing unit 23 Send to
  • the encryption / decryption processing unit 25 includes an encryption function 25A, a decryption function 25B, and a secret management information acquisition function 25C linked with these.
  • the encryption function 25A determines the account of the user terminal requesting the encryption, receives the contract data before encryption, and the secret management information acquired by the secret management information acquisition function 25C, and encrypts the requested item. Output contract data including encrypted items.
  • Decryption function 25B determines the account of the user terminal that requests decryption, receives contract data including the encryption item, and the secret management information acquired by secret management information acquisition function 25C, and decrypts the encryption item. , Output decrypted contract data.
  • the secret management information acquisition function 25C acquires the secret management information on the designated account from the verification terminal 1A via the verification terminal cooperation unit 21, and passes it to the encryption function 25A or the decryption function 25B.
  • FIG. 6 is a diagram showing a process of constructing concealment management information, which is executed by the intermediate servers 2A, 2B and 2C and the verification terminals 1A, 1B and 1C corresponding thereto, respectively.
  • the verification terminals 1A, 1B, and 1C will be collectively referred to as “verification terminal 1” in the following, but processing from each intermediate server to the verification terminal uses the corresponding verification terminal.
  • the user terminal 3A designates only the user terminals 3X and 3S as a destination to which the common key is distributed, and as the items to be encrypted, the contractor ("contractors") and the amount (“amount”) Explain the case of setting.
  • the intermediate server 2A generates a public key and a secret key corresponding to the public key for each of the accounts of the user terminals 3A, 3B, and 3C, and generates the public key into a transaction through the verification terminal cooperation unit 21. And transmits to the verification terminal 1 (step S1).
  • the intermediate server 2B and the intermediate server 2C individually generate the public key and the secret key for the user terminals 3X, 3Y and 3Z, and 3S, 3T and 3U, respectively, and the generated public key is verified by the verification terminal It is included in the transaction via the cooperation unit 21 and transmitted to the verification terminal 1 (steps S2 and S3).
  • the verification terminal 1 agrees on the transaction including the received public key according to the protocol of the block chain system, and registers the public key as the secret management information in the dispersion ledger 12A via the secret management function 11B (step S4).
  • the dispersion ledger 12A associates and stores an account for each user and a public key. Such registration processing can be performed, for example, at the time of account creation.
  • the intermediate server 2A is information indicating which item of the contract data transmitted from the user terminal 3A is to be encrypted with the common key (ie, the contractor “contractors” and the amount “amount” for contract1 and contract2) And the information (ie, user terminal 3X “org2.userX” and user terminal 3S “org3.userS”) indicating to which account the common key is distributed and the information is disclosed (step S5) .
  • the intermediate server 2A generates a different common key for each item for which encryption is designated by the user terminal 3A (step S6). Specifically, the intermediate server 2A generates four different common keys for “contract1.contractors”, “contract2.contractors”, “contract1.amount”, and “contract2.amount”.
  • the intermediate server 2A acquires the public key of each account for distributing the common key designated by the user terminal 3A from the concealment management information on the dispersion register via the verification terminal 1. Specifically, the intermediate server 2A requests the verification terminal 1 for secret management information including the public keys of the user terminal 3X and the user terminal 3S (step S7). The intermediate server 2A also acquires the public key of the user terminal 3A which is the request source account. The verification terminal 1 acquires the requested concealment management information from the dispersion ledger 12A, and transmits it to the intermediate server 2A (step S8).
  • the intermediate server 2A encrypts each common key with each acquired public key. Specifically, the intermediate server 2A is for the user terminal 3B encrypted with the public key of the user terminal 3A and the public key for the user terminal 3A encrypted with the public key of the user terminal 3A with respect to a certain common key. And the common key for the user terminal 3B encrypted with the public key of the user terminal 3S (step S9). The intermediate server 2A generates a transaction including “information indicating an encryption item” and “a common key for the encryption item” for each account to which the encrypted common key is distributed, to the verification terminal 1 Send (step S10).
  • the verification terminal 1 agrees the received transaction in accordance with the protocol of the block chain system, and registers the received transaction in the dispersion ledger 12A as the secret management information (step S11). As shown in the range R52, encrypted common key information is stored for the contractor ("contractors") and the amount ("amount"). Thus, the intermediate server 2A constructs secret management information.
  • FIG. 7 shows a functional block diagram of the user terminal 3A.
  • the user terminal 3A has a control unit 31, a display unit 32, and a storage unit 33.
  • the hardware configuration of the other user terminals is the same as the hardware configuration of the user terminal 3A, so the description will be omitted.
  • the control unit 31 includes one or more processors.
  • the control unit 31 executes a program defining a control procedure to control each functional unit of the user terminal 3A.
  • the display unit 32 is, for example, a display device such as a liquid crystal display, an organic EL (Electroluminescence) display, an inorganic EL display, and the like, but is not limited thereto.
  • the display unit 32 is configured as a touch screen, and can receive a selection operation by a user's finger or a stylus pen.
  • the selection operation is, for example, an operation such as pressing, touching, tapping, touching, or proximity.
  • the storage unit 33 can be configured by a semiconductor memory, a magnetic memory, or the like.
  • the storage unit 33 has a DB that stores arbitrary information such as a log, a program, and content.
  • the storage unit 33 may also function as a work memory.
  • Embodiment 1 the contract data is encrypted and decrypted on the premise that the common key has already been distributed to the designated account (registered in the dispersion register 12A) by the processing of FIG. That is, in the first embodiment, the intermediate server 2A performs encryption and decryption using the distributed common key. At this time, in a state where contract data in which a part of the items has already been encrypted is stored in dispersion ledger 12A, and further a request for encryption of contract data is received from the user terminal, the contract data of dispersion ledger 12A Is updated.
  • FIG. 8A is a flowchart showing a data encryption method performed by the intermediate server 2A in response to a request from a user terminal.
  • the contract data processing unit 23 when the contract data processing unit 23 receives the contract data transmitted by the user terminal, the contract data processing unit 23 requests the encryption / decryption processing unit 25 to encrypt the contract data (step S41).
  • the encryption function 25A determines the account of the user terminal that has requested the encryption, and via the secret management information acquisition function 25C, the dispersion ledger book Secret management information on the account is acquired from 12A (step S42).
  • the encryption function 25A includes a pair of an item of contract data having a common key (that is, an item of contract data that can be encrypted) included in the secret management information and an encrypted common key corresponding to the item. All are extracted (step S43).
  • the items of contract data that can be encrypted are, for example, an account for which org1.userA requested encryption in area R52 of FIG. 6, and in contract1.contractors, contract2.contractors, contract1.amount, and contract2.amount. is there.
  • the encryption function 25A performs the encryption process as shown in FIG. 8B using the item and the information on the common key (step S44).
  • the encryption function 25A encrypts an item of contract data that can be encrypted using the extracted common key.
  • Each common key is encrypted. Therefore, the encryption / decryption processing unit 25 decrypts each common key using the secret key stored in the secret key storage DB 24C (step S51).
  • the encryption function 25A encrypts each item of the contract data that can be encrypted with the decrypted common key (step S52). As a result, contract data in which some items of the contract data are encrypted is output.
  • the encryption / decryption processing unit 25 transmits the contract data in which some items are encrypted to the contract data processing unit 23 (step S53).
  • the contract data processing unit 23 transmits contract data in which a part of the items is encrypted to the verification terminal cooperation unit 21, and the verification terminal cooperation unit 21 includes the contract data in the transaction to verify the verification terminal 1A.
  • the verification terminal 1A agrees on the transaction according to the protocol of the block chain system, and registers contract data in which some items are encrypted in the distribution register.
  • FIG. 9 is a flowchart showing a data decryption method performed by the intermediate servers 2B and 2C.
  • the details are as follows.
  • the case where the decryption request is received from the user terminal 3X or the user terminal 3S for which the decryption of the encryption item is permitted will be described.
  • the encryption / decryption processing unit 25 does not execute the following decryption even if a decryption request is received from a user terminal for which decryption is not permitted, and the error screen or the encrypted item is blank. The displayed screen is returned to the user terminal.
  • the contract data processing unit 23 receives a decryption request for an encryption item of contract data from any user terminal. When the decryption request is received, the contract data processing unit 23 requests the encryption / decryption processing unit 25 to decrypt (step S61).
  • the secret management information acquisition function 25C of the encryption / decryption processing unit 25 acquires the secret management information and the contract data from the dispersion ledger 12A (step S62).
  • the secret management information acquisition function 25C acquires a list of all pairs of the encrypted item to which the common key has been distributed and the corresponding common key with respect to the account requiring decryption (step S63).
  • the common key included in the secret management information is encrypted with the public key of the account. Therefore, the encryption / decryption processing unit 25 acquires the secret key of the account from the secret key storage DB 24C (step S64), and decrypts all encrypted common keys using the secret key (step S65). ).
  • the encryption / decryption processing unit 25 decrypts all encrypted items of the contract data including the encrypted items using all the decrypted common keys (step S66). If encryption / decryption processing unit 25 determines that steps S65 to S66 have been executed for all of the decryptable encrypted items and the common key (Yes in step S67), the encrypted items are decrypted.
  • the contract data is transmitted to the contract data processing unit 23 (step S68). When the contract data acquisition function 23B of the contract data processing unit 23 acquires the contract data, it transmits the contract data to the account requiring the decryption. Thereby, the display unit of the user terminal 3X or the user terminal 3S displays the decrypted contract data. Thus, the user can view the contract data.
  • contract data can be encrypted and decrypted without using a centralized server. Therefore, it is possible to execute encryption and decryption of contract data while maintaining authority distribution.
  • the public key is separately generated for each account of the user having the access right to the encryption target item. Therefore, the user can flexibly specify the encryption item and the disclosure range of the contract data. In other words, users who do not have access can not steal data that they do not have access to.
  • the secret management information is managed on the dispersion ledger 12A, the complexity of the procedure for key concealment management or key management is reduced, and the operation cost and security risk are reduced. be able to.
  • the secret management information is registered in the dispersion ledger 12A via a transaction.
  • the concealment of contract data is performed by acquiring the concealment management information registered in the dispersion ledger 12A. For this reason, resistance to attacks on the secret management information can be enhanced.
  • the common key is generated for each of the encryption target items included in the contract data. Therefore, it is possible to flexibly specify which item is to be encrypted.
  • the intermediate server 2A uses the distributed common key. Encrypt the item corresponding to the common key. Therefore, when the contract data is encrypted, the process of newly registering the common key becomes unnecessary, and the processing load on the intermediate server 2A can be reduced.
  • the concealment system S since the concealment system S carries out key exchange on the block chain, past key exchange history such as who is allowed to refer to which item, who passed the common key, etc. Will remain as a record.
  • key tampering is more difficult and evidence is high compared to exchange of keys with an external server.
  • the intermediate server 2A encrypts the designated item using the common key on the secret management information, and registers the contract data.
  • the intermediate server 2A receives a request for registration of contract data, it always generates a new common key, encrypts a designated item, and registers the contract data.
  • the details of the second embodiment are as follows. The description overlapping in the first embodiment and the second embodiment is omitted.
  • the contract data processing unit 23 When receiving the contract data registration request from the user terminal, the contract data processing unit 23 designates which item of the contract data is to be encrypted and to which account the common key is to be distributed.
  • the designated content may be input by the user terminal 3A or may be set in advance by a setting file.
  • the key generation unit 22 newly generates a common key in response to the contract data registration request.
  • the intermediate server 2A constructs the secret management information by the method shown in FIG. Specifically, although the intermediate server 2A executes steps S7 to S11 shown in FIG. 6, since the content is duplicated, the description here is omitted.
  • the encryption function 25A acquires the secret management information from the dispersion ledger 12A via the secret management information acquisition function 25C.
  • the encryption function 25A encrypts a part of items of the contract data using the newly generated common key included in the secret management information.
  • the contract data processing unit 23 transmits the contract data in which a part of the items is encrypted to the verification terminal cooperation unit 21, includes the transaction in the transaction, and transmits to the verification terminal 1A.
  • the intermediate server 2A may notify the user terminal that is the disclosure target of the contract data.
  • the intermediate server 2A may notify that effect to the user terminal that is the disclosure object of the contract data.
  • the intermediate server or the user terminal is configured by a computer
  • a program describing processing contents for realizing each function is stored in a storage unit inside or outside the computer, and the central processing unit of the computer This can be realized by reading and executing this program by (CPU).
  • a program can be distributed, for example, by selling, transferring, lending, etc. a portable recording medium such as a DVD or a CD-ROM.
  • a program can be distributed, for example, by storing the program in storage means of a server on a network, and transferring the program from the server to another computer via the network.
  • a computer that executes such a program can temporarily store, for example, a program recorded on a portable recording medium or a program transferred from a server in its own storage means.
  • the computer may read the program directly from the portable recording medium and execute processing in accordance with the program.
  • the computer may sequentially execute processing in accordance with the received program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Accounting & Taxation (AREA)
  • Data Mining & Analysis (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

中央集権的な秘匿化サーバを置かなくとも、利用者が複雑な手順又は鍵の管理に煩わされることなく、分散台帳に登録する契約データの一部を柔軟に秘匿化して管理すること。　分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成するステップと、項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得するステップと、共通鍵を、前記アカウントごとの各公開鍵で暗号化するステップと、前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して分散台帳に登録するステップと、を含む、コンピュータが行うデータ登録方法。

Description

データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム
　本発明は、データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラムに関する。
　近年、中央集権的な管理を必要とせずに信頼性を担保可能な仕組みが、デジタル仮想通貨であるビットコインを中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みにおいては、やり取りされる情報の信頼性が分散ネットワーク内の合意形成のプロセスによって担保される。また、改ざん又は二重使用などの不正を系全体で防ぐことで健全性が保たれる。このブロックチェーンでは、参加者間の仮想通貨の取引情報（トランザクション）が「ブロック」という単位でまとめられ、各ブロックは数珠つなぎとなって時系列順に管理される。新たなブロックの承認は、Proof of Workなどの分散ネットワークにおける合意アルゴリズムによって成される。このことは、ブロック内部に記録された通貨取引が系全体で合意されたことを示す。このブロックチェーンを用いて管理される一連の取引情報の帳簿は「分散台帳」と呼ばれる。ネットワークに参加する各ノードは同一の分散台帳を保持する。
　近年では、分散台帳に通貨取引だけでなく、高度なスクリプトコードを登録し、スクリプトコードの実行とその結果についても合意を得るブロックチェーン基盤技術も開発されている。例えばEthereumやHyperledger Fabricに代表されるブロックチェーン基盤では、トランザクションを入力としてスクリプトコードを実行し、その実行結果をキーバリュー型のストアに格納し、その時のストアの代表値もブロックに記録する分散台帳を持つ（例えば非特許文献１）。前述の仮想通貨ではトランザクションは「誰から誰へいくら渡した」といった通貨の取引記録のみに限定された。一方、これら後継のブロックチェーン技術では、利用者自身が、トランザクションとスクリプトコードによって記録する情報をプログラマブルに設定可能である。そのため、証券取引、保険業務、著作権管理など通貨取引以外の様々な用途にブロックチェーンを応用することが容易になる。これらの基盤技術は、ある契約に関して参加者間で合意を得ることから、スマートコントラクト型のブロックチェーンと呼ばれている。
特開２０１７－５０７６３号公報
ＩＢＭ　Ｃｏｒｐｏｒａｔｉｏｎ、「はじめてのBlockchain」、[Online]、2016年9月15日、[平成29年10月3日検索]、インターネット(URL: https://www.ibm.com/developerworks/jp/cloud/library/j_cl-blockchain-basics-bluemix/index.html) 株式会社富士通研究所、「ブロックチェーンのセキュリティ強化技術を開発」、２．秘密分散鍵管理によるブロックチェーン上の文書秘匿化技術、[Online]、2016年10月19日、[平成29年10月3日検索]、インターネット(URL: http://pr.fujitsu.com/jp/news/2016/10/19.html)
　上記ブロックチェーンのシステムでは、全てのノード間において情報が公開されることが前提となっている。しかしながら、用途によってはトランザクションの一部の領域を秘匿化して、関係する参加者に限って公開したい場合がある。例えば、特許文献１に示す方法によれば、コンテンツの許諾管理に適用するために、仮想通貨型のブロックチェーンを介して、暗号化した情報を送受信することができる。この方式によれば、暗号化するデータの対象はコンテンツの共通鍵であり、権利者と利用者の二者間の端末に限定して秘匿情報がやり取りされている。しかしこの方式では、秘匿化する範囲を選択することができない。
　スマートコントラクト型のブロックチェーンのように利用者がプログラマブルに契約の項目を設定できる場合において、より柔軟に秘匿化の設計を行うことが求められている。例えば、貿易業務における貨物保険証券の取引にスマートコントラクト型のブロックチェーンを適用する場合、複数の項目において柔軟に秘匿化する項目を設定でき、かつ、保険会社・通知銀行・発行銀行など複数の異なる組織間の組み合わせで公開範囲を設定できることが求められている。この場合、複数の項目を有する契約データのうち、どの項目を暗号化しているのか、どの利用者に限って公開されているのか、復号化に使う鍵はどれか、といった管理情報が煩雑化する。更に、共通鍵を入手するまでに必要な鍵交換の手順並びに公開鍵及び秘密鍵の管理が煩雑化し、利用者がシステムを利用する際に運用面で大きな負担となる。
　このような課題に対して、非特許文献２に示すように、中央管理された秘匿化サーバをブロックチェーンシステム外に設けて対応することが考えられる。秘匿化サーバの内部には、秘匿化のための管理情報が保管され、利用者の要求に応じて暗号化・復号化の機能を提供する。秘匿化された情報は契約データに含められ、ブロックチェーンシステム内の分散台帳に保管される。秘匿化サーバによって暗号化の項目及び公開範囲が管理される。このため、利用者の負担は軽減される。一方で、非特許文献２では、ブロックチェーンシステムの特徴である権限の分散性は損われてしまう。例えば、秘匿化サーバの管理者が権限を乱用し、他社が格納した機密情報を覗き見るような内部不正は防ぐことが困難である。また、秘匿化サーバの管理者がサービスを停止した場合に、分散台帳に登録された暗号化データを利用者の権限のみで復号化することは容易ではない。また、ブロックチェーンシステム外で鍵の受け渡しが発生するため、誰が誰に鍵を渡したかの証拠が残らず、取引の証拠性を損ね得る。
　かかる点に鑑みてなされた本発明の目的は、中央集権的な秘匿化サーバを置かなくとも、利用者が複雑な手順又は鍵の管理に煩わされることなく、分散台帳に登録するデータの一部を柔軟に秘匿化して管理することができるデータ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラムを提供することにある。
　上記課題を解決するため、本実施形態のコンピュータにおけるデータ登録方法は、分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成するステップと、前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得するステップと、前記共通鍵を、前記アカウントごとの各公開鍵で暗号化するステップと、前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録するステップと、を含む。
　また、上記課題を解決するため、本実施形態のコンピュータにおけるデータ復号方法は、トランザクションを介して分散台帳に登録された、暗号化された項目を含むデータを取得するステップと、トランザクションを介して前記分散台帳に登録された秘匿管理情報を取得するステップと、前記秘匿管理情報から、前記暗号化された項目と、当該暗号化された項目を復号化するための、暗号化された共通鍵と、を取得するステップと、前記暗号化された共通鍵を、当該共通鍵に対応する秘密鍵を用いて復号化するステップと、前記復号化された共通鍵を用いて、前記暗号化された項目を復号化するステップと、を含む。
　また、上記課題を解決するため、本実施形態の秘匿管理情報のデータ構造は、トランザクションを介して分散台帳に登録されたデータの暗号化された項目に対するアクセス権限を有するユーザのアカウント情報と、前記暗号化された項目を示す情報と、前記暗号化された項目を復号化するための共通鍵を暗号化するために用いた公開鍵に関する情報と、前記公開鍵によって暗号化された前記共通鍵と、を含む。前記アカウント情報は、前記秘匿管理情報がどのユーザに対応するものかを特定する。前記共通鍵は、前記公開鍵に対応する秘密鍵を用いて復号化される。前記復号化された共通鍵は、前記暗号化された項目を復号化するために用いられる。
　また、上記課題を解決するため、本実施形態のコンピュータは、分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成し、前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得し、前記共通鍵を、前記アカウントごとの各公開鍵で暗号化し、前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録する、プロセッサを備える。
　また、上記課題を解決するため、本実施形態のプログラムは、コンピュータに、分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成するステップと、前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得するステップと、前記共通鍵を、前記アカウントごとの各公開鍵で暗号化するステップと、前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録するステップと、を実行させる。
　本発明に係るデータ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラムによれば、中央集権的な秘匿化サーバを置かなくとも、利用者が複雑な手順又は鍵の管理に煩わされることなく、分散台帳に登録するデータの一部を柔軟に秘匿化して管理することができる。
本実施形態の秘匿化システムの概略構成を示す機能ブロック図である。 暗号化前の契約データの一例を示す図である。 暗号化後の契約データの一例を示す図である。 本実施形態の検証端末の機能ブロック図である。 本実施形態の秘匿管理情報を示す図である。 本実施形態の中間サーバの機能ブロック図である。 本実施形態の秘匿管理情報の構築処理を示すシーケンス図である。 本実施形態のユーザ端末の機能ブロック図である。 実施形態１の中間サーバが実行する処理を示すフローチャートである。 図８Ａの暗号化処理のサブルーチンを示すフローチャートである。 中間サーバが実行する復号化処理を示すフローチャートである。
　図１は、本実施形態の秘匿化システムＳを示す機能ブロック図である。本実施形態の秘匿化システムＳは、ネットワークＮＷと、検証端末１Ａ、１Ｂ及び１Ｃと、中間サーバ２Ａ、２Ｂ及び２Ｃと、ユーザ端末３Ａ、３Ｂ、３Ｃ、３Ｘ、３Ｙ、３Ｚ、３Ｓ、３Ｔ及び３Ｕとを有する。本実施形態のネットワークＮＷはブロックチェーンネットワークである。本実施形態の検証端末１Ａ、１Ｂ及び１Ｃはブロックチェーン検証端末である。ユーザ端末３Ａ、３Ｂ及び３Ｃは組織１に設けられ、ユーザ端末３Ｘ、３Ｙ及び３Ｚは組織２に設けられ、ユーザ端末３Ｓ、３Ｔ及び３Ｕは組織３に設けられる。組織は例えば、保険会社、銀行等である。
　ユーザ端末３Ａ、３Ｂ及び３Ｃは中間サーバ２Ａを介して検証端末１Ａと接続する。ユーザ端末３Ｘ、３Ｙ及び３Ｚは中間サーバ２Ｂを介して検証端末１Ｂと接続する。ユーザ端末３Ｓ、３Ｔ及び３Ｕは中間サーバ２Ｃを介して検証端末１Ｃと接続する。
　以下、重複説明を避けるために、検証端末１Ａ、中間サーバ２Ａ並びにユーザ端末３Ａ、３Ｂ及び３Ｃが実行する処理を中心に説明する。しかし、その説明は、検証端末１Ｂ、中間サーバ２Ｂ並びにユーザ端末３Ｘ、３Ｙ及び３Ｚにもあてはまり、検証端末１Ｃ、中間サーバ２Ｃ並びにユーザ端末３Ｓ、３Ｔ及び３Ｕにもあてはまる。
　検証端末１Ａは、トランザクションの検証若しくは伝搬、後述する分散台帳１２Ａ（図３参照）への記録若しくは参照など、ブロックチェーンシステムを使用する上で基本的な機能を備えたソフトウェアを搭載する。検証端末１Ａは秘匿化システムＳを利用するための専用のソフトウェアではなく、EthereumやHyperledger Fabricなど汎用のブロックチェーン基盤を利用してよい。中間サーバ２Ａは、中間サーバ２Ａに接続された各ユーザ端末から要求を受け付け、検証端末１Ａと通信し、指定された処理を実行する。各中間サーバは、管理権限の分かれた組織単位で分散して運用される。一つの検証端末には一つの中間サーバが割り当てられる。一つの中間サーバに対して、同じ組織内の複数のユーザ端末が接続されてよい。しかし、ある組織のユーザ端末に接続された中間サーバは、他の組織のユーザ端末に直接的に接続されない。検証端末１Ａと中間サーバ２Ａとは必ずしも物理的に分かれている必要はなく、仮想化などを利用して同じ物理端末上に実装されてよい。
　検証端末１Ａ、１Ｂ及び１Ｃは、ネットワークＮＷを介して互いに接続される。図１に示す例では、ネットワークＮＷに検証端末が３つ接続されているが、その数は限定されない。また、図１に示す例では、中間サーバ２Ａ、２Ｂ及び２Ｃにユーザ端末が３つずつ接続されているが、その数は限定されない。以下では本実施形態の秘匿化システムＳの各機能を説明するが、秘匿化システムＳが備える他の機能を排除することを意図したものではない。
　図２Ａは、本実施形態で用いられる、構造化された契約データの例を示す。図２Ａに示すように、契約データにおいては、契約ＩＤ（「contract1」）に対し、日付（「date」）、内容（「description」）、契約者（「contractors」）、金額（「amount」）、請求金額（「charges」）等が対応付けられる。この契約データは複数人で交わされたある契約に関するデータである。契約データはユーザ入力によってユーザ端末で生成される。契約データの一部は秘匿化システムＳ全体には公開されず、後述する方法で暗号化（秘匿化）して分散台帳１２Ａに記録される。暗号化の実行後、図２Ｂの範囲Ｒ２１及び範囲Ｒ２２に示すように、契約データの一部の項目（「contractors」、「amount」及び「charges」）は暗号化される。分散台帳１２Ａに登録するデータは契約データに限られず、他の任意のデータが登録されてよい。
　復号化するための鍵は、秘匿化システムＳにより、指定されたユーザ端末のみに共有される。各中間サーバは復号化を自動的に実施する。このため、各ユーザ端末は図２Ｂのような暗号文を表示しない。よって、図２Ｂに示すような暗号文をユーザが直接目にすることはない。各ユーザ端末は、図２Ａに示すような平文を表示する。
　図３は、検証端末１Ａの機能ブロック図である。検証端末１Ａは、制御部１１と記憶部１２とを有する。検証端末１Ｂ及び１Ｃのハードウェア構成は検証端末１Ａのそれと同様であるため、説明を省略する。
　制御部１１は、１又は複数のプロセッサを含む。プロセッサは、種々の処理のためのプログラム及び演算中の情報を記憶する１又は複数のメモリを含んでよい。メモリは揮発性メモリ及び不揮発性メモリを含む。メモリは、プロセッサと独立しているメモリ、及びプロセッサの内蔵メモリを含む。プロセッサは特定のプログラムを読み込ませて特定の機能を実行する汎用のプロセッサ、及び、特定の処理に特化した専用のプロセッサを含む。専用のプロセッサは、特定用途向けＩＣ（ＡＳＩＣ；Application Specific Integrated Circuit）を含む。プロセッサは、プログラマブルロジックデバイス（ＰＬＤ；Programmable Logic Device）を含む。ＰＬＤは、ＦＰＧＡ（Field-Programmable Gate Array）を含む。制御部１１は、一つまたは複数のプロセッサが協働するＳｏＣ（System-on-a-Chip）、及びＳｉＰ（System In a Package）のいずれかであってよい。
　制御部１１は、契約データ保管機能１１Ａと秘匿管理機能１１Ｂとを有する。契約データ保管機能１１Ａと秘匿管理機能１１Ｂとはスクリプトコードで実装される。スクリプトコードは記憶部１２に格納される。スクリプトコードは、例えばスマートコントラクト型のブロックチェーン基盤のHyperledger Fabricでは「チェインコード」と呼ばれ、Ethereumでは「コントラクト」と呼ばれる分散実行可能なプログラムを指す。ブロックチェーンの基盤によっては、スクリプトコードは分散台帳１２Ａの内部に保管されている場合もある。一般的にスマートコントラクト型のブロックチェーンシステムは、ユーザ端末が発行したトランザクションに応じて、本スクリプトコードを実行し、実行結果について他の組織の検証端末１Ｂ又は１Ｃと合意を取る。実行結果であるキーバリュー型のデータ及び合意結果は、検証端末１Ａで保有されている分散台帳１２Ａへ記録される。
　記憶部１２は、半導体メモリ又は磁気メモリ等で構成される。記憶部１２は、ログ、プログラム及びコンテンツ等の任意の情報を格納するＤＢを有する。記憶部１２はワークメモリとしても機能してよい。記憶部１２が記憶する分散台帳１２Ａの内部のステートＤＢ１２Ａ２は、キーバリュー型で表現されるデータを格納する。ブロックチェーン特有の鎖状のデータストア１２Ａ１は、スクリプトコードの実行結果を含むステートＤＢ１２Ａ２のスナップショット（ハッシュ値など）を格納する。
　本実施形態において、検証端末１Ａは、利用するブロックチェーンのプロトコルに従い、契約データ保管機能１１Ａ及び秘匿管理機能１１Ｂとして示されるスクリプトコードを実行する。契約データ保管機能１１Ａは、中間サーバ２Ａから契約データを含むトランザクションを受け取り、ブロックチェーンのプロトコルに従って、当該トランザクションを分散台帳１２Ａに記録する。契約データは、暗号化対象の項目を含む場合、中間サーバ２Ａで暗号化（秘匿化）される。このため、契約データ保管機能１１Ａが受信する契約データは、図２Ｂに示すように一部が暗号化されている。暗号文は文字列として扱われるため、暗号化されていることを明示的に示すフラグが追加されてよい。
　秘匿管理機能１１Ｂは、中間サーバ２Aから秘匿化に必要な情報を含むトランザクションを受け取り、ブロックチェーンのプロトコルにしたがって、当該トランザクションを秘匿管理情報として分散台帳１２Ａに登録する。秘匿管理情報のデータ構造では、図４に例示するように、暗号化項目に対するアクセス権限を有する各ユーザのアカウント情報に対して、鍵交換に用いる公開鍵情報（範囲Ｒ４１参照）と、契約データのどの項目が暗号化されているかを示す情報（範囲Ｒ４２参照）と、その暗号化項目に対する共通鍵（前記公開鍵で暗号化済み）情報（範囲Ｒ４３参照）とが対応付けられる。ここでアカウントとは、ユーザを一意に特定するＩＤを示す。例えば図４に示す例では、組織１（org1）におけるユーザＡ（user A）のアカウント情報は、「org1.userA」などと示される。秘匿管理情報は、アカウントを識別するアイデンティティ情報（範囲Ｒ４４参照）（例えばＣＡ（認証局）発行の証明書又は署名検証用の公開鍵のハッシュなど）を含んでよい。検証端末１Ａは、アカウントとアイデンティティ情報とを照合することによって、トランザクションが、当該アカウントが発行したものか否かを検証することができる。このため、検証端末１Ａは、無権限のユーザによる、秘匿管理情報への不正な書き込みを防止することができる。
　図５は、中間サーバ２Ａの機能ブロック図を示す。中間サーバ２Ｂ及び２Ｃのハードウェア構成は中間サーバ２Ａのそれと同様であるため、説明を省略する。
　中間サーバ２Ａは、検証端末連携部２１と、鍵生成部２２と、契約データ処理部２３と、鍵登録部２４と、暗号・復号化処理部２５とを有する。これらの機能部は、中間サーバ２Ａのプロセッサによって実行される。
　検証端末連携部２１は、トランザクション送信機能２１Ａと、分散台帳参照機能２１Ｂと、署名用鍵保管ＤＢ２１Ｃとを有する。トランザクション送信機能２１Ａは、各機能部から情報を受け取り、分散台帳１２Ａに記録するために必要なトランザクションを生成し、検証端末１Ａへ送信する。ブロックチェーンシステムにおけるトランザクションの生成にはアカウントごとに紐づけられた電子署名鍵が必要である。電子署名鍵は署名用鍵保管ＤＢ２１Ｃに保管される。分散台帳参照機能２１Ｂは、検証端末１Ａが保有する分散台帳１２Ａを参照する機能を持ち、各機能部からの要求に応じて分散台帳１２Ａ上の契約データ又は秘匿管理情報を取得する。
　鍵生成部２２は、公開鍵・秘密鍵生成機能２２Ａと、共通鍵生成機能２２Ｂとを有する。公開鍵・秘密鍵生成機能２２Ａは、他の機能部の要求に応じて、公開鍵及び／又は秘密鍵を生成する。本実施形態の公開鍵・秘密鍵生成機能２２Ａは、ユーザのアカウントごとに公開鍵と秘密鍵とのペアを生成する。公開鍵・秘密鍵生成機能２２Ａは、公開鍵と秘密鍵とのペアを定期的に更新可能である。更新時において、中間サーバ２Ａは、更新後の公開鍵と秘密鍵とのペアを秘匿管理情報として分散台帳１２Ａへ再登録する。公開鍵及び秘密鍵のペアは、共通鍵を共有する際の鍵交換を行うために利用される。公開鍵・秘密鍵生成機能２２Ａは、公開鍵及び秘密鍵を生成するために、例えばＲＳＡ公開鍵暗号方式を用いる。公開鍵・秘密鍵生成機能２２Ａは、生成した鍵ペアを鍵登録部２４へ渡す。
　共通鍵生成機能２２Ｂは、暗号・復号化処理部２５にて契約データの項目を暗号化又は復号化に用いる共通鍵を生成する。本実施形態では、暗号化・復号化の一例として、例えばAES－GCMなどの共通鍵暗号方式を利用する。すなわち、本実施形態では、暗号化と復号化とで用いる鍵は同一である。以下ではその鍵を共通鍵と称する。本実施形態の共通鍵生成機能２２Ｂは、データに含まれる暗号化対象項目ごとに共通鍵を生成する。例えば、項目Ａをユーザ端末３Ａ、ユーザ端末３Ｘ及びユーザ端末３Ｓのみが参照可能なようにする場合、共通鍵生成機能２２Ｂは、項目Ａ用の共通鍵を生成する。そして、共通鍵生成機能２２Ｂは、ユーザ端末３Ａの公開鍵で当該共通鍵を暗号化し、ユーザ端末３Ｘの公開鍵で当該共通鍵を暗号化し、ユーザ端末３Ｓの公開鍵で当該共通鍵を暗号化する。このとき、項目Ａが、共通鍵と対応する項目である。詳細は後述するが、下記実施形態１では、指定されたアカウントに共通鍵が既に配布されているときに契約データの登録要求を受けた場合には、その共通鍵が利用される。一方、下記実施形態２では、契約データの登録要求を受ける度に共通鍵が新たに生成される。
　契約データ処理部２３は、契約データ登録機能２３Ａ及び契約データ取得機能２３Ｂを有する。
　契約データ登録機能２３Ａは、契約データの一部の項目を暗号化することが指定された場合に、暗号・復号化処理部２５に暗号化を要求する。契約データ登録機能２３Ａは、暗号化の実施後に、契約データを検証端末連携部２１へ送信する。契約データは検証端末連携部２１を介してトランザクションとして発行され、ブロックチェーンシステムのプロセスに従い、分散台帳１２Ａに記録される。すなわち契約データ登録機能２３Ａは、契約データを、トランザクションを介して分散台帳１２Ａへ登録する。
　契約データ取得機能２３Ｂは、取得した契約データの一部に暗号化された項目が存在する場合に、暗号・復号化処理部２５に復号化を要求する。復号化が実行されると、契約データ取得機能２３Ｂは契約データを要求元の端末に送信する。
　鍵登録部２４は、公開鍵登録機能２４Ａ、秘密鍵保管機能２４Ｂ及び秘密鍵保管ＤＢ２４Ｃを有する。公開鍵登録機能２４Ａは、鍵生成部２２で生成した公開鍵を、検証端末１Ａを介して、分散台帳１２Ａに登録する。このとき公開鍵は、トランザクションを介して登録される。秘密鍵保管機能２４Ｂは、鍵生成部２２で生成した秘密鍵を、外部に漏洩しないよう、中間サーバ２Ａ内の秘密鍵保管ＤＢ２４Ｃに登録する。
　暗号・復号化処理部２５は、契約データ処理部２３からの要求に応じて、暗号化又は復号化が要求された項目に対して暗号化又は復号化の処理を実行し、契約データ処理部２３に送信する。暗号・復号化処理部２５は、暗号化機能２５Ａ、復号化機能２５Ｂ及び、これらと連携する秘匿管理情報取得機能２５Ｃを有する。
　暗号化機能２５Ａは、暗号化を要求するユーザ端末のアカウントを判定し、暗号化前の契約データと、秘匿管理情報取得機能２５Ｃが取得した秘匿管理情報とを受け付け、要求された項目を暗号化し、暗号化済みの項目を含む契約データを出力する。
　復号化機能２５Ｂは、復号化を要求するユーザ端末のアカウントを判定し、暗号化項目を含む契約データと、秘匿管理情報取得機能２５Ｃが取得した秘匿管理情報とを受け付け、暗号化項目を復号し、復号された契約データを出力する。
　秘匿管理情報取得機能２５Ｃは、検証端末１Ａから検証端末連携部２１を介して、指定されたアカウントに関する秘匿管理情報を取得し、暗号化機能２５Ａ又は復号化機能２５Ｂに渡す。
　図６は、中間サーバ２Ａ、２Ｂ及び２Ｃと、それぞれに対応する検証端末１Ａ、１Ｂ及び１Ｃとが実行する、秘匿管理情報の構築処理を示す図である。検証端末１Ａ、１Ｂ及び１Ｃは、以下、３つを総称して検証端末１と称するが、それぞれの中間サーバから検証端末に対する処理は対応する検証端末を用いる。ここでは一例として、ユーザ端末３Ａが、共通鍵を配布する先としてユーザ端末３Ｘ及び３Ｓのみを指定し、且つ、暗号化される項目として、契約者（「contractors」）と金額（「amount」）を設定した場合を説明する。
　中間サーバ２Ａは、ユーザ端末３Ａ、３Ｂ及び３Ｃのアカウントのそれぞれに対し、公開鍵及び当該公開鍵に対応する秘密鍵を生成し、生成した公開鍵を、検証端末連携部２１を介してトランザクションに含め、検証端末１へ送信する（ステップＳ１）。同様に、中間サーバ２Ｂ及び中間サーバ２Ｃは、それぞれユーザ端末３Ｘ、３Ｙ及び３Ｚ、並びに、３Ｓ、３Ｔ及び３Ｕに対し、公開鍵及び秘密鍵を個別に生成し、生成した公開鍵を、検証端末連携部２１を介してトランザクションに含め、検証端末１へ送信する（ステップＳ２及びステップＳ３）。
　検証端末１は受信した公開鍵を含むトランザクションについて、ブロックチェーンシステムのプロトコルに従って合意し、秘匿管理機能１１Ｂを介して公開鍵を秘匿管理情報として分散台帳１２Ａに登録する（ステップＳ４）。範囲Ｒ５１に示すように、分散台帳１２Ａは、ユーザごとのアカウントと、公開鍵とを対応付けて記憶する。このような登録処理は、例えばアカウント作成時に実行可能である。
　任意の時点で、中間サーバ２Ａは、ユーザ端末３Ａから送信された契約データのどの項目を共通鍵で暗号化するかを示す情報（すなわち、contract1とcontract2に対する契約者「contractors」と金額「amount」の項目）と、どのアカウントに共通鍵を配布し情報を公開するかを示す情報（すなわち、ユーザ端末３Ｘ「org2.userX」及びユーザ端末３Ｓ「org3.userS」）とを受信する（ステップＳ５）。
　中間サーバ２Ａは、前記ユーザ端末３Ａにより暗号化を指定された各項目に対して、それぞれ異なる共通鍵を生成する（ステップＳ６）。具体的には、中間サーバ２Ａは、「contract1.contractors」、「contract2.contractors」、「contract1.amount」及び「contract2.amount」に対して異なる４つの共通鍵を生成する。
　中間サーバ２Ａは、前記ユーザ端末３Ａにより指定された、共通鍵を配布する各アカウントの公開鍵を、検証端末１を介して、分散台帳上の秘匿管理情報より取得する。具体的には、中間サーバ２Ａは、ユーザ端末３Ｘ及びユーザ端末３Ｓの公開鍵を含む秘匿管理情報を、検証端末１に対して要求する（ステップＳ７）。また、中間サーバ２Ａは、要求元アカウントであるユーザ端末３Ａの公開鍵についても取得する。検証端末１は要求された秘匿管理情報を分散台帳１２Ａから取得し、中間サーバ２Ａへ送信する（ステップＳ８）。
　中間サーバ２Ａは、各共通鍵を、取得した各公開鍵でそれぞれ暗号化する。具体的には、中間サーバ２Ａは、ある共通鍵に対して、ユーザ端末３Ａの公開鍵で暗号化したユーザ端末３Ａ用の共通鍵と、ユーザ端末３Ｘの公開鍵で暗号化したユーザ端末３Ｂ用の共通鍵と、ユーザ端末３Ｓの公開鍵で暗号化したユーザ端末３Ｂ用の共通鍵と、を生成する（ステップＳ９）。中間サーバ２Ａは、暗号化した共通鍵の配布先の各アカウントに対して、「暗号化項目を示す情報」と「その暗号化項目に対する共通鍵」とを含むトランザクションを生成し、検証端末１へ送信する（ステップＳ１０）。検証端末１は受信したトランザクションを、ブロックチェーンシステムのプロトコルに従い合意し、分散台帳１２Ａに秘匿管理情報として登録する（ステップＳ１１）。範囲Ｒ５２に示すように、契約者（「contractors」）と金額（「amount」）に対して、暗号化された共通鍵の情報が格納されている。このように、中間サーバ２Ａは秘匿管理情報を構築する。
　図７は、ユーザ端末３Ａの機能ブロック図を示す。ユーザ端末３Ａは、制御部３１、表示部３２及び記憶部３３を有する。他のユーザ端末のハードウェア構成はユーザ端末３Ａのハードウェア構成と同一であるため、説明を省略する。
　制御部３１は、一つ又は複数のプロセッサを含む。制御部３１は、制御手順を規定したプログラムを実行して、ユーザ端末３Ａの各機能部を制御する。
　表示部３２は例えば、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、無機ＥＬディスプレイ等の表示デバイス等であるが、これらに限られない。本実施形態では一例として、表示部３２はタッチスクリーンとして構成され、ユーザの指又はスタイラスペンによる選択操作を受け付けることができる。選択操作は例えば、押下、タッチ、タップ、接触、近接等の操作である。
　記憶部３３は半導体メモリ又は磁気メモリ等で構成されることができる。記憶部３３は、ログ、プログラム及びコンテンツ等の任意の情報を格納するＤＢを有する。記憶部３３は、ワークメモリとしても機能してよい。
　運用ポリシーに応じた、暗号化及び復号化に関する例示的な実施形態が下記に示される。
［実施形態１］
　実施形態１では、図６の処理により、指定されたアカウントに共通鍵が既に配布（分散台帳１２Ａに登録）されている前提で、契約データの暗号化および復号化を行う。すなわち、実施形態１では、中間サーバ２Ａは、配布済みの共通鍵を利用して暗号化および復号化を行う。このとき、分散台帳１２Ａ上に、既に項目の一部が暗号化された契約データが格納されている状態で、さらに契約データの暗号化要求をユーザ端末から受け付けた場合、分散台帳１２Ａの契約データは更新される。
　図８Ａは、ユーザ端末からの要求に応じて、中間サーバ２Ａが実行するデータ暗号方法を示すフローチャートである。図８Ａに示すように、契約データ処理部２３は、ユーザ端末が送信した契約データを受信すると、暗号・復号化処理部２５へ、契約データの暗号化を要求する（ステップＳ４１）。
　暗号・復号化処理部２５が契約データの暗号化の要求を受けると、暗号化機能２５Ａは、暗号化を要求したユーザ端末のアカウントを判定し、秘匿管理情報取得機能２５Ｃを介して、分散台帳１２Ａより当該アカウントに関する秘匿管理情報を取得する（ステップＳ４２）。暗号化機能２５Ａは、秘匿管理情報に含まれる、共通鍵を持つ契約データの項目（すなわち、暗号化が可能な契約データの項目）と、当該項目に対応する暗号化された共通鍵のペアを全て抽出する（ステップＳ４３）。暗号化が可能な契約データの項目は、例えば、図６の範囲Ｒ５２で、org1.userAが暗号化を要求したアカウントとすると、contract1.contractors、contract2.contractors、contract1.amount、及びcontract2.amountである。暗号化機能２５Ａは、当該項目とその共通鍵の情報を用いて、図８Ｂに示すように暗号化処理を行う（ステップＳ４４）。
　図８Ｂに示すように、暗号化機能２５Ａは、抽出した共通鍵を用いて、暗号化可能な契約データの項目に対して暗号化を行う。各共通鍵は暗号化されている。そこで、暗号・復号化処理部２５は、秘密鍵保管ＤＢ２４Ｃに記憶される秘密鍵を用いて、各共通鍵を復号化する（ステップＳ５１）。
　暗号化機能２５Ａは、暗号化可能な契約データの各項目に対して、復号化されたそれぞれの共通鍵で暗号化を実施する（ステップＳ５２）。これにより、契約データのうち、一部の項目が暗号化された契約データが出力される。暗号・復号化処理部２５は、一部の項目が暗号化された契約データを、契約データ処理部２３へ送信する（ステップＳ５３）。
　図８Ａに戻り、契約データ処理部２３は、一部の項目が暗号化された契約データを検証端末連携部２１へ送信し、検証端末連携部２１は当該契約データをトランザクションに含めて検証端末１Ａに送信する（ステップＳ４５）。検証端末１Ａはブロックチェーンシステムのプロトコルに従い、当該トランザクションに関して合意し、一部の項目が暗号化された契約データを分散台帳へ登録する。
　図９は、中間サーバ２Ｂ、２Ｃが実行するデータ復号方法を示すフローチャートである。詳細は次の通りである。ここでは、暗号化項目の復号化が許可された、ユーザ端末３Ｘ又はユーザ端末３Ｓから復号化要求を受信した場合を説明する。なお、暗号・復号化処理部２５は、復号化が許可されていないユーザ端末から復号化要求を受信しても、下記の復号化を実行せず、エラー画面又は暗号化された項目が空白に表示される画面を当該ユーザ端末へ返す。
　契約データ処理部２３は、任意のユーザ端末から、契約データの暗号化項目に対する復号化要求を受信する。復号化要求を受信すると、契約データ処理部２３は、暗号・復号化処理部２５へ復号化を要求する（ステップＳ６１）。
　暗号・復号化処理部２５の秘匿管理情報取得機能２５Ｃは、分散台帳１２Ａから秘匿管理情報及び契約データを取得する（ステップＳ６２）。秘匿管理情報取得機能２５Ｃは、復号化を要求するアカウントに関して、共通鍵が配布された暗号化項目と、それに対応する共通鍵とのペアの一覧を全て取得する（ステップＳ６３）。ここで秘匿管理情報に含まれる上記共通鍵は、上記アカウントの公開鍵で暗号化されている。そこで、暗号・復号化処理部２５は、秘密鍵保管ＤＢ２４Ｃから上記アカウントの秘密鍵を取得し（ステップＳ６４）、当該秘密鍵を用いて、暗号化された共通鍵を全て復号化する（ステップＳ６５）。
　暗号・復号化処理部２５は、暗号化項目が含まれる契約データについて、上記全ての復号化した共通鍵を用いて、暗号化された全ての項目を復号化する（ステップＳ６６）。暗号・復号化処理部２５は、復号化可能な全ての暗号化項目と共通鍵とに対し、ステップＳ６５からステップＳ６６を実行したと判定すると（ステップＳ６７のＹｅｓ）、暗号化項目が復号化された契約データを契約データ処理部２３に送信する（ステップＳ６８）。契約データ処理部２３の契約データ取得機能２３Ｂは、契約データを取得すると、復号化を要求するアカウントに対し、当該契約データを送信する。これにより、ユーザ端末３Ｘ又はユーザ端末３Ｓの表示部は、復号化された契約データを表示する。このため、ユーザは当該契約データを閲覧することができる。
　本実施形態によれば、ブロックチェーンを用いることで、中央集権的なサーバを用いずに契約データを暗号化及び復号化することができる。このため、権限分散性を保ちながら、契約データの暗号化及び復号化を実行することが可能である。
　また、本実施形態によれば、公開鍵は、暗号化対象項目に対するアクセス権限を有するユーザのアカウントごとに別々に生成される。このため、ユーザ自身が契約データの暗号化項目及び公開範囲を柔軟に指定することができる。換言すれば、アクセス権限のないユーザは、閲覧権限のないデータを盗み見ることができない。
　また、本実施形態によれば、秘匿管理情報は分散台帳１２Ａ上で管理されるため、秘匿化のための手続き又は鍵の管理の煩雑さを軽減し、運用上のコスト及びセキュリティリスクを低減することができる。
　また、本実施形態によれば、秘匿管理情報はトランザクションを介して分散台帳１２Ａに登録される。契約データの秘匿化は分散台帳１２Ａに登録された秘匿管理情報を取得して行われる。このため、秘匿管理情報への攻撃に対する耐性を高めることができる。
　また、本実施形態によれば、共通鍵は、契約データに含まれる暗号化対象項目ごとに生成される。このため、どの項目を暗号化するかを柔軟に指定することができる。
　また、本実施形態によれば、共通鍵が、項目に対するアクセス権限を有するユーザのアカウントへ配布済み（分散台帳１２Ａに登録済み）のとき、中間サーバ２Ａは、当該配布済みの共通鍵を利用して共通鍵と対応する項目を暗号化する。このため、契約データを暗号化する際に、新たに共通鍵を登録する処理が不要となり、中間サーバ２Ａの処理負荷を低減することができる。
　また、本実施形態によれば、秘匿化システムＳはブロックチェーン上で鍵交換を行うため、誰にどの項目の参照を許可したか、誰に共通鍵を渡したか、等の過去の鍵交換履歴が記録として残る。更に外部サーバでの鍵のやり取りに比べ、鍵の改ざんが困難であり且つ証拠性が高い。
　上述の実施形態は代表的な例として説明されている。しかし本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形又は変更が可能である。例えば、実施形態の構成図に記載の複数の構成ブロックを１つに組み合わせたり、あるいは１つの構成ブロックを分割したりすることが可能である。
［実施形態２］
　上記実施形態１では、中間サーバ２Ａは、秘匿管理情報上の共通鍵を用いて、指定された項目を暗号化して契約データを登録する。一方で実施形態２では、中間サーバ２Ａは、契約データの登録の要求を受ける度に常に新しい共通鍵を生成し、指定された項目を暗号化して契約データを登録する。実施形態２の詳細は次の通りである。実施形態１と実施形態２とで重複する説明は省略する。
　契約データ処理部２３は、ユーザ端末から契約データの登録要求を受信すると、契約データのどの項目を暗号化するかと、どのアカウントに共通鍵を配布するかを指定する。指定内容は、ユーザ端末３Ａによって入力されてよいし、設定ファイルによって事前に設定されてもよい。鍵生成部２２は、契約データの登録要求に応じて、新たに共通鍵を生成する。なお、これらの処理は、図６のステップＳ５およびＳ６に相当する。図６のステップＳ１～Ｓ４の処理は、事前に行われているものとする。
　中間サーバ２Ａは、図６に示す手法で秘匿管理情報を構築する。具体的には中間サーバ２Ａは、図６に示すステップＳ７からステップＳ１１を実行するが、内容が重複するためここでの説明は省略する。
　暗号化機能２５Ａは、秘匿管理情報取得機能２５Ｃを介して、分散台帳１２Ａより、秘匿管理情報を取得する。暗号化機能２５Ａは、秘匿管理情報に含まれる、新たに生成された共通鍵を用いて、契約データの一部の項目を暗号化する。契約データ処理部２３は、一部の項目が暗号化された契約データを検証端末連携部２１へ送信し、トランザクションに含めて検証端末１Ａへ送信する。
［実施形態３］
　実施形態３において中間サーバ２Ａは、項目の一部が暗号化された契約データとその共通鍵を登録したとき、当該契約データの公開対象であるユーザ端末に通知してよい。また、契約データを書き込んだユーザが共通鍵を変更したとき、中間サーバ２Ａはその旨を、契約データの公開対象であるユーザ端末へ通知してよい。
　検証端末、中間サーバ又はユーザ端末をコンピュータで構成する場合、各機能を実現する処理内容を記述したプログラムを、当該コンピュータの内部又は外部の記憶手段に格納しておき、当該コンピュータの中央演算処理装置（ＣＰＵ）によってこのプログラムを読み出して実行させることで実現することができる。また、このようなプログラムは、例えばＤＶＤ又はＣＤ－ＲＯＭ等の可搬型記録媒体の販売、譲渡、貸与等により流通させることができる。また、そのようなプログラムを、例えばネットワーク上にあるサーバの記憶手段に記憶しておき、ネットワークを介してサーバから他のコンピュータにそのプログラムを転送することにより、流通させることができる。また、そのようなプログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム又はサーバから転送されたプログラムを、一旦、自己の記憶手段に格納することができる。また、このプログラムの別の実施態様として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよい。更に、このコンピュータにサーバからプログラムが転送される度に、コンピュータは、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。
Ｓ　秘匿化システム
１Ａ、１Ｂ、１Ｃ　検証端末
１１　　制御部
１１Ａ　契約データ保管機能
１１Ｂ　秘匿管理機能
１２　　記憶部
１２Ａ　分散台帳
１２Ａ１　データストア
１２Ａ２　ステートＤＢ
２Ａ、２Ｂ、２Ｃ　中間サーバ
２１　　検証端末連携部
２１Ａ　トランザクション送信機能
２１Ｂ　分散台帳参照機能
２１Ｃ　署名用鍵保管ＤＢ
２２　　鍵生成部
２２Ａ　公開鍵・秘密鍵生成機能
２２Ｂ　共通鍵生成機能
２３　　契約データ処理部
２３Ａ　契約データ登録機能
２３Ｂ　契約データ取得機能
２４　　鍵登録部
２４Ａ　公開鍵登録機能
２４Ｂ　秘密鍵保管機能
２４Ｃ　秘密鍵保管ＤＢ
２５　　暗号・復号化処理部
２５Ａ　暗号化機能
２５Ｂ　復号化機能
２５Ｃ　秘匿管理情報取得機能
３Ａ、３Ｂ、３Ｃ、３Ｘ、３Ｙ、３Ｚ、３Ｓ、３Ｔ、３Ｕ　ユーザ端末
３１　　制御部
３２　　表示部
３３　　記憶部

Claims (8)

  1. 　コンピュータが行うデータ登録方法であって、
    　分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成するステップと、
    　前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得するステップと、
    　前記共通鍵を、前記アカウントごとの各公開鍵で暗号化するステップと、
    　前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録するステップと、
    　を含む、データ登録方法。
  2. 　請求項１に記載のデータ登録方法において、
    　前記共通鍵を用いて、前記データに含まれる、前記共通鍵と対応する項目を暗号化するステップと、
    　前記暗号化された項目を含むデータを、トランザクションを介して前記分散台帳に登録するステップと、
    　を更に含むデータ登録方法。
  3. 　請求項１又は２に記載のデータ登録方法において、
    　前記共通鍵は、前記データに含まれる暗号化対象項目ごとに生成される、データ登録方法。
  4. 　請求項１乃至３のいずれか一項に記載のデータ登録方法において、
    　前記共通鍵を生成するステップは、前記データの前記分散台帳への登録要求を受け付ける度に、前記共通鍵を生成する
    　、データ登録方法。
  5. 　コンピュータが行うデータ復号方法であって、
    　トランザクションを介して分散台帳に登録された、暗号化された項目を含むデータを取得するステップと、
    　トランザクションを介して前記分散台帳に登録された秘匿管理情報を取得するステップと、
    　前記秘匿管理情報から、前記暗号化された項目と、当該暗号化された項目を復号化するための、暗号化された共通鍵と、を取得するステップと、
    　前記暗号化された共通鍵を、当該共通鍵に対応する秘密鍵を用いて復号化するステップと、
    　前記復号化された共通鍵を用いて、前記暗号化された項目を復号化するステップと、
    　を含む、データ復号方法。
  6. 　秘匿管理情報のデータ構造であって、
    　トランザクションを介して分散台帳に登録されたデータの暗号化された項目に対するアクセス権限を有するユーザのアカウント情報と、
    　前記暗号化された項目を示す情報と、
    　前記暗号化された項目を復号化するための共通鍵を暗号化するために用いる公開鍵に関する情報と、
    　前記公開鍵によって暗号化された前記共通鍵と、
    　を含み、
    　前記アカウント情報は、前記秘匿管理情報がどのユーザに対応するものかを特定し、
    　前記共通鍵は、前記公開鍵に対応する秘密鍵を用いて復号化され、
    　前記復号化された共通鍵は、前記暗号化された項目を復号化するために用いられる、
    　データ構造。
  7. 　分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成し、
    　前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得し、
    　前記共通鍵を、前記アカウントごとの各公開鍵で暗号化し、
    　前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録する、
    　プロセッサを備えるコンピュータ。
  8. 　コンピュータに、
    　分散台帳に登録するデータに含まれる項目を暗号化及び復号化するための共通鍵を生成するステップと、
    　前記項目に対するアクセス権限を有するユーザのアカウントごとに公開鍵を取得するステップと、
    　前記共通鍵を、前記アカウントごとの各公開鍵で暗号化するステップと、
    　前記アカウントごとに暗号化された各共通鍵を、トランザクションを介して前記分散台帳に登録するステップと、
    　を実行させるプログラム。
PCT/JP2018/024401 2017-10-27 2018-06-27 データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム WO2019082442A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP18870135.3A EP3703306A4 (en) 2017-10-27 2018-06-27 DATA REGISTRATION PROCEDURES, DATA DECODING PROCEDURES, DATA STRUCTURE, COMPUTER AND PROGRAM
JP2019549840A JP7235668B2 (ja) 2017-10-27 2018-06-27 登録方法、コンピュータ、及びプログラム
US16/757,736 US11720689B2 (en) 2017-10-27 2018-06-27 Data registration method, data decryption method, data structure, computer, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017208384 2017-10-27
JP2017-208384 2017-10-27

Publications (1)

Publication Number Publication Date
WO2019082442A1 true WO2019082442A1 (ja) 2019-05-02

Family

ID=66246369

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/024401 WO2019082442A1 (ja) 2017-10-27 2018-06-27 データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム

Country Status (4)

Country Link
US (1) US11720689B2 (ja)
EP (1) EP3703306A4 (ja)
JP (1) JP7235668B2 (ja)
WO (1) WO2019082442A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020255382A1 (ja) * 2019-06-21 2020-12-24 富士通株式会社 コンテンツ取引システム、コンテンツ取引方法、鍵管理装置、及び鍵管理プログラム
WO2021149449A1 (ja) * 2020-01-23 2021-07-29 学校法人東京理科大学 登録装置、検証装置、識別装置、及び個体識別システム
JP2022020604A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 分散型電子契約証明プラットフォーム
JP7469133B2 (ja) 2019-05-06 2024-04-16 フィッシャー－ローズマウント システムズ，インコーポレイテッド 分散型台帳を使用するプライバシー保護型のビッグデータ共有のための枠組み

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7090903B2 (ja) * 2018-11-09 2022-06-27 国立大学法人東北大学 情報処理システム、データ提供方法、および情報処理システムの製造方法
WO2021034264A1 (en) * 2019-08-22 2021-02-25 Quantumciel Pte. Ltd. Device, system and method for providing information security

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007156970A (ja) * 2005-12-07 2007-06-21 Fujitsu Ltd 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法
JP2008077235A (ja) * 2006-09-19 2008-04-03 Ricoh Co Ltd 情報記録再生方法、情報記録再生システム、情報閲覧管理装置、画像形成装置、コンピュータプログラム及び記録媒体
JP2017050763A (ja) 2015-09-03 2017-03-09 日本電信電話株式会社 許諾情報管理システム、利用者端末、権利者端末、許諾情報管理方法、および、許諾情報管理プログラム
JP2017195627A (ja) * 2017-06-23 2017-10-26 株式会社エヌ・ティ・ティ・データ 情報処理装置、情報処理方法およびプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10552829B2 (en) * 2015-05-26 2020-02-04 tZERO Group, Inc. Obfuscation of intent in transactions using cryptographic techniques
EP3380984A4 (en) 2015-11-24 2019-07-31 Ben-Ari, Adi SYSTEM AND METHOD FOR THE PROTECTION OF DATA BY INTELLIGENT BLOCKCHAIN CONTRACT
JP6608256B2 (ja) 2015-11-26 2019-11-20 株式会社ｂｉｔＦｌｙｅｒ Ｂｌｏｃｋｃｈａｉｎ 電子データの存在証明プログラムおよび存在証明サーバ
CA3008705C (en) * 2015-12-14 2020-03-10 Coinplug, Inc. System for issuing public certificate on basis of block chain, and method for issuing public certificate on basis of block chain by using same
US10013573B2 (en) * 2015-12-16 2018-07-03 International Business Machines Corporation Personal ledger blockchain

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007156970A (ja) * 2005-12-07 2007-06-21 Fujitsu Ltd 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法
JP2008077235A (ja) * 2006-09-19 2008-04-03 Ricoh Co Ltd 情報記録再生方法、情報記録再生システム、情報閲覧管理装置、画像形成装置、コンピュータプログラム及び記録媒体
JP2017050763A (ja) 2015-09-03 2017-03-09 日本電信電話株式会社 許諾情報管理システム、利用者端末、権利者端末、許諾情報管理方法、および、許諾情報管理プログラム
JP2017195627A (ja) * 2017-06-23 2017-10-26 株式会社エヌ・ティ・ティ・データ 情報処理装置、情報処理方法およびプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Blockchain for beginners", 15 September 2016, IBM CORPORATION
"Development of Security Reinforcement Technology for Blockchain", vol. 2, 19 October 2016, FUJITSU LABORATORIES LTD., article "Document Encryption Technology on Blockchain through Secret Sharing-based Key Management"
See also references of EP3703306A4

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7469133B2 (ja) 2019-05-06 2024-04-16 フィッシャー－ローズマウント システムズ，インコーポレイテッド 分散型台帳を使用するプライバシー保護型のビッグデータ共有のための枠組み
WO2020255382A1 (ja) * 2019-06-21 2020-12-24 富士通株式会社 コンテンツ取引システム、コンテンツ取引方法、鍵管理装置、及び鍵管理プログラム
JPWO2020255382A1 (ja) * 2019-06-21 2021-12-09 富士通株式会社 コンテンツ取引システム、コンテンツ取引方法、鍵管理装置、及び鍵管理プログラム
WO2021149449A1 (ja) * 2020-01-23 2021-07-29 学校法人東京理科大学 登録装置、検証装置、識別装置、及び個体識別システム
JPWO2021149449A1 (ja) * 2020-01-23 2021-07-29
JP7011276B2 (ja) 2020-01-23 2022-01-26 学校法人東京理科大学 登録装置、検証装置、識別装置、及び個体識別システム
JP2022020604A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 分散型電子契約証明プラットフォーム

Also Published As

Publication number Publication date
JPWO2019082442A1 (ja) 2020-10-22
EP3703306A4 (en) 2021-07-28
JP7235668B2 (ja) 2023-03-08
EP3703306A1 (en) 2020-09-02
US11720689B2 (en) 2023-08-08
US20210192059A1 (en) 2021-06-24

Similar Documents

Publication Publication Date Title
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
US11238543B2 (en) Payroll based blockchain identity
JP7235668B2 (ja) 登録方法、コンピュータ、及びプログラム
US20200119904A1 (en) Tamper-proof privileged user access system logs
US9031876B2 (en) Managing keys for encrypted shared documents
CN101484903B (zh) 用于控制从存储器装置供应的信息的系统和方法
JP2021516004A (ja) ランダム・シーケンスを生成および検証するための分散型台帳
JP2012518329A (ja) 信頼済みクラウドコンピューティングおよびサービスに関するフレームワーク
NO329299B1 (no) Domene-baserte tillitsmodeller for rettighetsforvaltning av innhold
US11128457B2 (en) Cryptographic key generation using external entropy generation
CN115176247A (zh) 使用成对的去中心化标识符的委托
EP4026291B1 (en) Control of the delegated use of did-related data
EP3806385B1 (en) Cryptologic blockchain interoperability membership system
EP3777022A1 (en) Distributed access control
JP2015526048A (ja) 記録のための暗号化データ記憶装置
CN115191104A (zh) 由去中心化标识符锚定的去中心化标识
JP2023043870A (ja) ユーザ・データ・プライバシを管理するための方法及びシステム
CN114372242A (zh) 密文数据的处理方法、权限管理服务器和解密服务器
CN110914826A (zh) 用于分布式数据映射的系统和方法
JP2021081777A (ja) 組織間の情報連携を制御するシステム
JP2019068327A (ja) ユーザ管理装置、ユーザ管理システム
CN116527404B (zh) 基于区块链的数字藏品定向分享方法及系统
US20240106657A1 (en) Method and apparatus for posting a user message of a user in an internet forum
US20230028555A1 (en) Associating decentralized identifiers with one or more devices
Fakhar et al. Comparative analysis on security mechanisms in cloud

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019549840

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018870135

Country of ref document: EP

Effective date: 20200527