JP2019068327A - User management device, user management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage user information with appropriate access control without installing a specific user administrator and an administrator terminal in a decentralized environment. SOLUTION: A user management device has a first decryption key for decrypting information encrypted with a first encryption key, identification information for identifying a user, and a user encrypted with a second encryption key. It holds encryption attribute information which is attribute information and data indicating reference information for referencing the encryption attribute information, and the reference information includes a second decryption key encrypted with the first encryption key. , The second decryption key is a key for decrypting the information encrypted by the second encryption key, the second decryption key is obtained from the reference information by using the first decryption key, and the second decryption key is obtained. The user's attribute information is acquired from the encrypted attribute information using the above, an electronic signature is generated when the acquired attribute information satisfies a predetermined condition, and the identification information and the electronic signature are output. [Selection diagram] Fig. 1

Description

  The present invention relates to a user management apparatus and a user management method.

  Distributed ledger technology (or block chain) as a technology to replace transactions implemented via trusted central authority such as financial institutions and governments with direct transactions by P2P (Peer to Peer) between users Technology). In particular, there is a technology for performing payment transactions using a virtual currency called Bitcoin (registered trademark, hereinafter the same) without the need for a central authority such as a bank. In bitcoin, after a node called minor on transaction data (hereinafter also referred to as transaction) determines the legitimacy on the P2P network, determination processing is performed in a task of calculating a specific hash value called proof of work. Transactions that have been determined are grouped into one block and described in a distribution ledger called a block chain (hereinafter also referred to as BC).

  Furthermore, in recent years, based on the above-described BC implemented in Bitcoin, various derivative techniques have been proposed and evolved regarding BC and distributed ledger. The main features of the current BC are: (1) in the transaction among participants on the BC network, to establish the transaction by consensus formation or approval by the participants (optional or specific) rather than the central authority ( 2) A plurality of transactions are grouped as blocks, recorded in a dispersion ledger in a beaded bridge, and subjected to hash calculation for successive blocks, making tampering difficult, (3) all participants share the same ledger data By doing this, it may be possible to confirm the transaction among all the participants.

  From such characteristics as described above, such distributed ledger technology such as BC is a field of financial field, IoT (Internet of Things), etc. as a mechanism to manage and share reliable data, and execute and manage transactions based on contracts. Applications in a wide range of fields are being considered. By using a platform for providing a distributed ledger (hereinafter referred to as distributed ledger base), information sharing among a plurality of entities (eg, a consortium of a specific industry and a plurality of companies related to a supply chain, etc.) without management by a central authority And can trade. Hereinafter, a network configured by participants (participant nodes) participating in the distributed register is also referred to as a block chain network.

  The distribution ledger is not only (trade) data but also system logic in the distribution ledger to be applicable not only to simple virtual currency trading like bitcoin but also to complex trading conditions and various applications. Manage business logic. These logics are called smart contracts (hereinafter also referred to as SCs).

  There is also a technology related to a distributed ledger base having an execution function of SC. In the distributed ledger base, nodes (also referred to as TX hereinafter) are accepted while forming an agreement at a predetermined level of agreement between nodes, and each node executes TX to share information (ledger) on a plurality of nodes. . Also, these nodes include a smart contract (SC) execution function that executes predetermined logic for TX.

  In order to put the system built using these dispersion ledger technologies (hereinafter, dispersion ledger system) into production operation, user management, etc., as in the conventional system (eg, Web system including Web server and DB server) System operation management of (including, for example, backup and restoration of ledger, and service suspension etc.). Japanese Patent Laid-Open No. 2006-180472 (Patent Document 1) describes an electronic signature method implemented in user management in a conventional system. Specifically, in this publication, "The electronic image is divided into a plurality of components, the feature value of each of the components is calculated, and the signature is generated from the combination of the feature values. The components are deleted. If you do, replace with replacement data prepared in advance for each component and save only the feature value At the time of verification, the replaced component uses the saved feature value, and others use the newly calculated feature value to verify For generating a signature for comparison and verifying the signature attached to the electronic image (see abstract).

JP, 2006-180472, A

  On the other hand, in the distributed ledger system, a BC network is constructed and operated by a plurality of entities forming a consortium or the like. In other words, the distributed ledger system is configured across multiple organizations. With respect to such a dispersion ledger system, as a method of operation management of a conventional system, a first method in which all operators are operated and managed by a single operator, and operators of each node (for example, owning nodes of each organization Person) can be considered as the second method of operation management individually.

  When the first method is used, the operation is centralized and there is a problem that the strength of non-centralization characteristic of the BC system is diminished. The first method can not cope with multi-vendor operation. In the case of using the second method, there is a problem that the administrator and the policy are different for each organization, and can not be operated with the same arrangement and timing. In particular, when using a consortium type service that spans multiple subjects, it becomes an issue which subject performs user management and user authentication.

  In addition, in the distributed ledger system, there are many cases where there is no administrator of the entire system with absolute authority, and it is difficult to carry out strict user management and user authentication in existing systems as they are and to share them across the entire consortium It is. Therefore, it is difficult to apply user management using an electronic signature as described in Patent Document 1 as it is to the dispersion ledger system.

  As a simple solution to this problem, a user management system is built on the smart contract of the distributed ledger, and the user ID, user attribute information, and information necessary for services such as authentication information are described there, and the entire consortium By sharing user information, user management can be realized even under non-centralization.

  However, for example, the user's attribute information (eg, age, company name, and deposit amount) may be sensitive information, so it should be disclosed only to the consortium with the proper access right. is there. That is, when managing and operating user information on a distributed ledger in a non-centralized environment, it is necessary to appropriately access control the information.

  In order to solve the above-mentioned subject, one mode of the present invention adopts the following composition. A user management apparatus, comprising: a processor and a memory, wherein the memory is a first decryption key for decrypting information encrypted with a first encryption key, identification information for identifying a user, a second encryption key Encrypted attribute information which is attribute information of the user encrypted in step b. Transaction data indicating reference information for referring to the encrypted attribute information, the reference information being the first encryption A second decryption key encrypted with a key, wherein the second decryption key is a key for decrypting information encrypted with the second encryption key, and the processor is configured to: Acquiring the second decryption key included in the reference information using the second decryption key, decrypting the encrypted attribute information using the second decryption key, and acquiring the attribute information of the user, Electronic signature when the attribute information satisfies a predetermined condition , And outputs the signature transaction data including the digital signature the and the generated identification information, the user management device.

  According to one aspect of the present invention, management of user information for which appropriate access control has been performed is performed in a non-centralized environment such as, for example, a distributed ledger, without installing specific user administrators and administrator terminals. be able to.

  Problems, configurations, and effects other than those described above will be apparent from the description of the embodiments below.

FIG. 1 is a block diagram showing an example of a configuration of a user management system in Embodiment 1. FIG. 7 is a block diagram showing an example of a hardware configuration of a user terminal in the first embodiment. FIG. 8 is a sequence diagram showing an example of advance key distribution processing in the first embodiment. FIG. 8 is a sequence diagram showing an example of user information registration processing, signature processing, and verification processing according to the first embodiment. 5 is an example of a data format of a user information table in Embodiment 1. 5 is an example of a data format of an encrypted transaction in Embodiment 1. 5 is an example of a data format of a query transaction in Embodiment 1. 5 is an example of a data format of encrypted data in Embodiment 1. 5 is an example of a data format of a signature transaction in Embodiment 1. 5 is an example of a data format of encrypted data in Embodiment 1. 7 is a flowchart illustrating an example of encrypted transaction generation processing according to the first embodiment. 7 is a flowchart illustrating an example of a signature transaction generation process according to the first embodiment. 15 is another example of the data format of the user information table in the first embodiment. 15 is another example of the data format of the user information table in the first embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. It should be noted that the present embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. The same reference numerals are given to the same configuration in each drawing.

  In the user management system of this embodiment, when managing and operating user information on the dispersion ledger in the non-centralized environment, the user terminal registers the encrypted attribute information in the dispersion ledger. Furthermore, the user management system encrypts the key used for the encryption with the public key of the signer terminal and registers the key in the distribution register. Further, after the signer terminal requested from the user terminal confirms the attribute information, the electronic signature is generated in the encrypted attribute information, and the signature is registered in the distribution register. This indicates that the authentication by the signer terminal has been completed. The verifier terminal that verifies the attribute information of the user verifies the signature by the signer terminal on the distributed register, and verifies that the verification by the signer terminal has been performed on the attribute information. The verifier terminal does not necessarily need a centralizer because it determines the success and failure of verification according to its own policy.

  FIG. 1 is a block diagram showing a configuration example of a user management system. The user management system includes a user terminal 100, a verifier terminal 200, a signer terminal 300, and a transaction approver terminal 400. Each configuration included in the user management system can mutually transmit and receive information via the network 500.

  The user terminal 100 requests the registration of the user information in the dispersion register of the transaction approver terminal 400. The user terminal 100 has a public key / private key pair generation program 110 and an encrypted transaction generation program 111. The verifier terminal 200 verifies the user information. The verifier terminal 200 has a public key / private key pair generation program 210, a query generation program 211, and a verification program 212.

  The signer terminal 300 electronically signs the user information on the dispersion register of the transaction approver terminal 400. The signer terminal 300 has a public key / private key pair generation program 310, a query generation program 311, and a signature transaction generation program 312. The transaction approver terminal 400 executes the dispersion register and transaction verification and approval processing, and updates the state information (the user information table 900 in this embodiment) held by the transaction approver terminal 400 according to the execution result. The transaction approver terminal 400 has a public key / private key pair generation program 410, a transaction approval program 411, and a user information table 900.

  FIG. 2 is a block diagram showing an example of the hardware configuration of the user terminal 100. As shown in FIG. The hardware configurations of the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400 are, for example, the same as the hardware configuration of the user terminal 100, and thus the description thereof will be omitted. The user terminal 100 may be, for example, a computer in which the CPU 101, the auxiliary storage device 102, the memory 103, the display device 105, the input / output interface 106, and the communication interface 107 are connected via the internal signal line 104. Configured

  The CPU 101 includes a processor and executes a program stored in the memory 103. The memory 103 includes a ROM, which is a non-volatile storage element, and a RAM, which is a volatile storage element. The ROM stores an immutable program (for example, BIOS). The RAM is a high-speed and volatile storage element such as a dynamic random access memory (DRAM), and temporarily stores a program executed by the CPU 101 and data used when the program is executed.

  The auxiliary storage device 102 is, for example, a large-capacity and non-volatile storage device such as a magnetic storage device (HDD) or a flash memory (SSD), and stores programs executed by the CPU 101 and data used when executing the programs. . That is, the program is read from the auxiliary storage device 102, loaded into the memory 103, and executed by the CPU 101.

  The input / output interface 106 is an interface to which a keyboard, a mouse, and the like are connected and receives an input from an operator, and a display device, a printer, and the like are connected to output an execution result of a program in a format visible to the operator. .

  The communication interface 107 is a network interface device that controls communication with another device according to a predetermined protocol. The communication interface 107 also includes, for example, a serial interface such as USB.

  The program executed by the CPU 101 is provided to the user terminal 100 via removable media (CD-ROM, flash memory, etc.) or a network, and is stored in the non-volatile auxiliary storage device 102 which is a non-temporary storage medium. For this reason, the user terminal 100 may have an interface for reading data from removable media.

  The user terminal 100 is a computer system configured physically on one computer or on a plurality of logically or physically configured computers, and operates in different threads on the same computer. It may also operate on a virtual computer built on multiple physical computer resources. The same applies to the other terminals.

  Note that, for example, the CPU 101 functions as a public key / secret key pair generation unit by operating according to the public key / secret key pair generation program 110 loaded into the memory 103, and generates the encrypted transaction loaded in the memory 103. By operating according to the program 111, it functions as an encrypted transaction generation unit. The same applies to the relationship between programs and CPUs in other terminals.

  FIG. 5 is a view showing an example of a user information table 900 for user management on the dispersion register which the transaction approver terminal 400 holds. The user information table 900 includes, for example, a user name field, an attribute field, a referable person field, and a digital signature field. A detailed description of each field will be described later along with the process shown in FIG. In the present embodiment, the user name is an example of information that uniquely identifies the user.

  FIG. 3 is a sequence diagram showing an example of advance key distribution processing executed among the user terminal 100, the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400.

  First, the public key / private key pair generation program 110 of the user terminal 100 generates “pk-user” which is a public key and “sk-user” which is a secret key corresponding to the public key (S301). Similarly, the public key / private key pair generation program 210 of the verifier terminal 200 generates “pk-verifier” which is a public key and “sk-verifier” which is a secret key corresponding to the public key. (S302).

  Similarly, the public key / private key pair generation program 310 of the signer terminal 300 generates "pk-signer" which is a public key and "sk-signer" which is a secret key corresponding to the public key. (S303). Similarly, the public key / private key pair generation program 410 of the transaction approver terminal 400 has a public key "pk-transaction approver" and a private key "sk-transaction approver" corresponding to the public key. Are generated (S304). Note that, for example, a technique such as RSA encryption or elliptic curve cryptography is used to create a pair of public key and secret key in the present embodiment.

  Next, the public key / private key pair generation program 110 of the user terminal 100 transmits the public key “pk-user” generated in step S301 to the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400 ( S305 to S307). Similarly, the public key / private key pair generation program 210 of the verifier terminal 200 transmits the public key "pk-verifier" generated in step S302 to the user terminal 100, the signer terminal 300, and the transaction approver terminal 400. (S308 to S310).

  Similarly, the public key / private key pair generation program 310 of the signer terminal 300 generates the public key "pk-signer (D300)" generated in step S303 with the user terminal 100, the verifier terminal 200, and the transaction approver terminal 400. (S311 to S313). Next, the public key / private key pair generation program 410 of the transaction approver terminal 400 transmits the public key "pk-transaction approver" generated in step S304 to the user terminal 100, the verifier terminal 200, and the signer terminal 300. (S314 to S316), and the advance key distribution process is finished. By the above process, the public key and the secret key are generated on each of the user terminal 100, the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400, and the public key is distributed mutually.

  FIG. 4 is a sequence diagram showing an example of registration, signature and verification processing of user information in the user management system. The following example shows an example in which the user name of the user terminal 100 is "Alice" and the age "25" is registered as Alice's attribute information. In the present embodiment, the user terminal 100 registers user information in the dispersion register, and the signer terminal 300 electronically signs the user information on the dispersion register after confirmation of the user information, and the verifier terminal 200 A process for verifying user information is illustrated.

  First, the encrypted transaction generation program 111 of the user terminal 100 executes an encrypted transaction generation process to generate an encrypted transaction to be registered in the dispersion ledger (S401), and the generated encrypted transaction is used as all transaction approver terminals It transmits to 400 (S402). The encrypted transaction generation program 111 may not necessarily transmit the completed encrypted transaction to all the transaction approver terminals 400. For example, a predetermined policy, an instruction input to the user terminal 100, etc. , And may be transmitted only to some of the transaction approver terminals 400.

  FIG. 6 is an example of the data format of the encrypted transaction. The encrypted transaction has the same type of column as the user information table 900. In the example of FIG. 6, the user name of the user terminal 100 is "Alice", and the attribute of the user (age in the example of FIG. 6) is "25 years old". The encrypted transaction in the example of FIG. 6 is [Alice] as the value of the user name, [Enc (K, 25)] as the value of the attribute, and [Pub-Enc (pk-signer, K] as the value of the referable person. , Pub-Enc (pk-verifier, K)], [-(blank)] is held as the value of the electronic signature.

  Enc (K, X) represents a ciphertext of the common key cryptosystem in which the plaintext [X] is encrypted by the secret key [K]. Note that, as the common key encryption method, for example, an existing method such as AES (Advanced Encryption Standard) encryption is used. Also, Pub-Enc (pk-Y, K) indicates a ciphertext of the public key cryptosystem in which plaintext [K] is encrypted by the public key "pk-Y". In addition, as a public key cryptosystem, for example, an existing cryptosystem such as RSA cryptosystem and elliptic curve cryptosystem is used. [X] and [Y] may be ciphertext.

  It returns to the explanation of FIG. Next, the transaction approval program 411 of the transaction approver terminal 400 having received the encrypted transaction executes a transaction approval process (S403). If the approval result is successful, the transaction approval program 411 registers the encrypted transaction in the user information table 900 on the distributed ledger in step S403. On the other hand, if the approval result is a failure, the transaction approval program 411 discards the received encrypted transaction in step S403. As a method of transaction approval processing, a proof of work method may be used, a practical byzantine fault tolerance (PBFT) method may be used, or other transaction approval technology for distributed ledger is used. May be

  Next, the query generation program 311 of the signer terminal 300 generates a query transaction in the query generation process for acquiring user information registered in the dispersion register (S404), and approves all the generated query transactions. It transmits to the user terminal 400 (S405). The query generation program 311 of the signer terminal 300 may not necessarily transmit the completed query transaction to all the transaction approver terminals 400, and may be input to, for example, a predetermined policy or the signer terminal 300. According to the instruction etc., it may be transmitted only to some of the transaction approver terminals 400.

  The query generation program 311 periodically executes, for example, the processing of steps S404 to S405. In addition, when the signer terminal 300 is notified that the user terminal 100 has transmitted the encrypted transaction to the dispersion register, and the signer terminal 300 receives the notification, the query generation program 311 performs the processing of steps S404 to S405. You may process.

  In the case where the user identification information for the user of the user terminal 100 (for example, user attribute information and information for identifying the user) is stored in advance in the auxiliary storage device of the signer terminal 300, the user's An identity verification may be performed. Specifically, for example, when the signer who is the user of the signer terminal 300 performs identity verification of the user of the user terminal 100 or the like by phone call or face-to-face contact, the identity verification information is acquired. The signer terminal 300 receives an input of the acquired user information via the input device. In this case, the query generation program 311 generates a query transaction when the input user's information and the user's information stored in advance in the auxiliary storage device of the signer terminal 300 match. If not, an error is output to the display device of the signer terminal 300 and the user terminal 100, for example. The signer who is the user of the signer terminal 300 may directly input the result of the match determination to the signer terminal 300 via an input device or the like.

  FIG. 7 is a view showing an example of the data format of the query transaction generated in step S404. In the query transaction of FIG. 7, it is described that SELECT WHERE username = [Alice]. That is, the query transaction of FIG. 7 is a query transaction for acquiring a record related to “Alice” which is a user name of the user information table 900 on the distribution register. In addition, the query transaction by another query system may be generated in step S404.

  It returns to the explanation of FIG. Next, the transaction approval program 411 of the transaction approver terminal 400 that has received the query transaction searches the user information table 900 on the dispersion ledger for encrypted data corresponding to the received query transaction, and sends it to the signer terminal 300 (S406). If encrypted data corresponding to the query transaction does not exist in the user information table 900, the transaction approval program 411 sends an error back to the signer terminal 300.

  FIG. 8 is a diagram showing an example of the data format of the encrypted data transmitted in step S406. The example of FIG. 8 is an example of the encrypted data for the query transaction whose user name is “Alice” in the example of FIG. 7, and the record of the user information table 900 whose value of the user name is “Alice” is encrypted data. It has been sent as.

  It returns to the explanation of FIG. Next, the signature transaction generation program 312 of the signer terminal 300 that has received the encrypted data uses the secret key “sk—signer generated in the public key / secret key pair generation process in step S303. "Decrypted using plaintext" and verify plaintext attribute information obtained as a result of decryption (S407).

  If the verification result in step S407 is a failure, for example, the signature transaction generation program 312 notifies the user terminal 100 of an error, and ends the processing of FIG.

  If the verification result is successful in step S407, the signature transaction generation program 312 generates an electronic signature for encrypted data using the secret key "sk-signer" generated in step S304, and generates an electronic signature The signature transaction including the signature is generated, and the generated signature transaction is transmitted to the transaction approver terminal 400 (S408). Note that the signature transaction generation program 312 does not have to transmit the generated signature transaction to all the transaction approver terminals 400. For example, the signature transaction generation program 312 follows a predetermined policy or an instruction input to the signer terminal 300. , And may be transmitted only to some of the transaction approver terminals 400.

  FIG. 9 is a diagram showing an example of the data format of the signature transaction. FIG. 9 is an example of a signature transaction generated when the verification result for the attribute information of the user name value is “Alice” is successful. The electronic signature field stores [Signed by Signer], which is the value of the electronic signature generated using “sk−signer” which is the secret key of the signer terminal 300.

  In the example of the signature transaction in FIG. 9, although the attribute column and the referable person column are blank, for example, attribute information (Alice's encrypted attribute information [Enc (K, 25 years old)]) or Alice is displayed in the attribute column. Attribute information [25 years old]) may be stored. Also, [Signed by Signer] which is the value of the electronic signature section can perform signature verification using "pk-signer" which is the signer's public key. An existing method such as RSA signature may be used for signature generation and signature verification, for example.

  It returns to the explanation of FIG. Next, the transaction approval program 411 of the transaction approver terminal 400 having received the signature transaction executes a transaction approval process (S409). If the approval result is a success, the transaction approval program 411 registers the electronic signature stored in the signature transaction in the record corresponding to the user indicated by the signature transaction in the user information table 900 on the dispersion register in step S409. Do. On the other hand, if the approval result is a failure, the transaction approval program 411 discards the received encrypted transaction in step S409.

  Next, the query generation program 211 of the verifier terminal 200 generates a query transaction by executing a query generation process for acquiring user information registered in the dispersion register (S410), and generates the generated query transaction. It transmits to the transaction approver terminal 400 (S411). The query generation program 211 of the verifier terminal 200 may not necessarily transmit the generated query transaction to all the transaction approver terminals 400, and may be input to, for example, a predetermined policy or the verifier terminal 200. According to the instruction etc., it may be transmitted only to some of the transaction approver terminals 400.

  The query transaction generated in step S410 has, for example, the data format shown in FIG. The query generation program 211 of the verifier terminal 200 executes the processing of steps S410 to S411 periodically, for example. In addition, the verifier terminal 200 may be notified that the user terminal 100 has transmitted the encrypted transaction to the distribution register, and the query generation program 211 may perform the processing of step S410 to step S411 when the notification is received.

  Next, the transaction approval program 411 of the transaction approver terminal 400 that has received the query transaction transmitted in step S411 searches the user information table 900 for encrypted data corresponding to the received query transaction, and the verifier terminal Reply to 200 (S412). If encrypted data corresponding to the query transaction does not exist in the user information table 900, the transaction approval program 411 sends an error back to the verifier terminal 200.

  FIG. 10 is a diagram showing an example of the encrypted data data format transmitted in step S411. The example of FIG. 10 is an example of the encrypted data for the query transaction whose user name is “Alice” in the example of FIG. 9, and the record of the user information table 900 whose value of the user name is “Alice” is encrypted data. Since the signature transaction has been received in step S408, the digital signature field of the record whose user name in the user information table 900 is [Alice] is updated. Therefore, although the electronic signature field is blank in the encrypted data of FIG. 8, [Signed by Signer] is stored in the electronic signature field of the encrypted data of FIG.

  It returns to the explanation of FIG. Next, the verification program 212 of the verifier terminal 200 that receives the encrypted data from the transaction approver terminal 400 decrypts the received encrypted data using the secret key “sk-verifier” generated in step S302. And verify the decrypted plaintext attribute information (S413).

  In the verification of the attribute information in step S413, the verification program 212 determines whether the plaintext attribute information satisfies, for example, a predetermined condition (for example, when the attribute information indicates an age, the age is predetermined). It is verified whether it is included in the range (eg 20 years old and 60 years old etc). In step S413, the verification program 212 verifies the electronic signature included in the received encrypted data. In step S413, if the verification result is a failure, the verification program 212 outputs an error to the display device or the like of the verifier terminal 200 and ends the processing, and if the verification result is a success, the verification program 212 verifies A display indicating that the result is successful is output to the display device or the like of the verifier terminal 200, and the process is ended.

  The user management system of this embodiment executes management of user information for which appropriate access control has been performed without installing a specific user administrator and administrator terminal even on the dispersion ledger by the process shown in FIG. can do.

  FIG. 11 is a flowchart illustrating an example of the details of the generation process of the encrypted transaction in step S401. First, the encrypted transaction generation program 111 of the user terminal 100, for example, outputs [Alice] which is a user name corresponding to the user terminal 100, and sets the user name (S1101). The user terminal 100 may receive an input of a user name from the user via, for example, an input device or the like.

  Next, the encrypted transaction generation program 111 executes a common key generation algorithm to generate and output [K] which is a common key for attribute information encryption (S1102).

  Next, the encrypted transaction generation program 111 encrypts the age [25], which is the attribute value of the plaintext of “Alice”, using the common key encryption algorithm and the common key “K” to obtain the attribute value. [Enc (K, 25 years old)] is generated and output (S1103).

  Next, the encrypted transaction generation program 111 sets a referable person who can refer to the encrypted attribute of the user (S1104). Here, an example in which the signer terminal 300 and the verifier terminal 200 are referable persons will be described. In step S1104, the encrypted transaction generation program 111 receives an input of information indicating a referable person, for example, via an input device or the like.

  In step S1104, the encrypted transaction generation program 111 is a ciphertext [Pub-Enc (pk-signer, K) obtained by encrypting the common key "K" with "pk-signer" which is the public key of the signer terminal 300. ], And further generates a ciphertext [Pub-Enc (pk-verifier, K)] obtained by encrypting the common key "K" with "pk-verifier", which is the public key of verifier terminal 200. Output these ciphertexts as referable persons.

  Next, the encrypted transaction generation program 111 stores the above-mentioned output value in each data field of the encrypted transaction (S1105), and ends the generation processing of the encrypted transaction. That is, the encrypted transaction generation program 111 is: user name = [Alice], attribute = [Enc (K, 25 years old)], referable person = [Pub-Enc (pk-signer, K)], [Pub- Enc (pk-verifier, K)], and electronic signature = [-] ([-] indicates a blank) are stored in each data field in the encrypted transaction.

  FIG. 12 is a flowchart showing an example of the details of the signature transaction generation process in step S407. Hereinafter, a signature transaction generation process for encrypted data in FIG. 8 will be described.

  First, the signature transaction generation program 312 of the signer terminal 300 receives the encrypted data from the transaction approver terminal 400 (S1202), and executes decryption processing (S1202). In step S 1202, the signature transaction generation program 312 uses [Pub-Enc (pk-signer, K)] stored in the referable person column of the encrypted data as the secret key “sk-signer of the signer terminal 300. To obtain the common key "K".

  Next, the signature transaction generation program 312 decrypts the attribute [Enc (K, 25)] of the encrypted data using the common key “K” acquired in step S1202, and outputs plaintext 25 And verifying the attribute that is the plaintext (S1203). The signature transaction generation program 312 has succeeded in verification when, for example, an attribute that is a plain text and an attribute of the user (here, “Alice”) held in advance by the signer terminal 300 match as a verification process. If it does not match, it is determined that the verification has failed. Further, in the verification process, the verification result obtained after the user of the signer terminal 300 performs identity verification and the like of the user Alice of the user terminal 100 by telephone or face-to-face with respect to the user Alice corresponding to the user terminal 100 , And may be input to the signer terminal 300.

  In addition, not only attribute information but information which specifies a user can be used for verification processing. That is, if the information specifying the user is included in the encrypted data, the information may be used in the verification process. When the signature transaction generation program 312 determines that the verification result is a failure (S1203: verification failure), for example, an error is output to the display device of the signer terminal 300 and the user terminal 100 (S1204) to generate a signature transaction. End the process.

  When the signature transaction generation program 312 determines that the verification result is a failure (S1203: verification success), the signature transaction generation program 312 executes signature generation processing (S1205). In step S1205, the signature transaction generation program 312 generates a digital signature algorithm and a secret key “sk-signer” for the user name [Alice] that is the target data of the electronic signature and the attribute: [Enc (K, 25 years old)]. And generate an electronic signature [Signed by Signer], and output the electronic signature: [Signed by Signer]. Next, the signature transaction generation program 312 stores the user name = [Alice] and the electronic signature = [Signed by Signer] in each data field of the signature transaction data (S1206), and ends the signature transaction generation processing. .

  FIG. 13 is a diagram showing another example of the user information table 900. As shown in FIG. Although the user information table 900 of FIG. 5 has only one attribute column, the user information table 900 of FIG. 13 has a plurality of attribute columns (attribute 1 column,..., Attribute n column). Allows multiple types of attributes to be stored.

FIG. 14 is a diagram showing another example of the user information table 900. As shown in FIG. In the example of FIG. 14, the attributes stored in the same record of the user information table 900 are encrypted using different encryption methods and / or encryption keys. Specifically, in the record at the top of the user information table 900 in FIG. 14, the attribute 1 column is Enc ₁ (K ₁ , 25 years old),..., And the attribute n column is Enc _n (K _n , female) As such, encryption is performed using a common key / public key encryption scheme and / or an encryption key that are different for each attribute.

  Also, for example, different referable persons may be set for each attribute in the user information table 900. That is, the user terminal 100 may set an access right for each attribute by registering a different decryption key for each referable person in the data field of the referable person column.

  Further, as a method of encrypting the attribute, multiple encryption such as encryption of a ciphertext by another encryption method may be used. Specifically, for example, when the age "25", which is a plaintext, is encrypted with the first common key, the ciphertext "20 or more" is generated, and the ciphertext "20 or more" is generated using the second common key. It is assumed that encryption produces a ciphertext that does not indicate age. For example, the user terminal 100 may refer to a person who can obtain the first common key and the second common key, a person who can obtain the second common key, and the first common key and the second common key. The access level in the same attribute information can be set by determining the referable person who can not acquire any of the common keys.

  In step S407, the signature transaction generation program 312 may generate a signature at this time using the redactable signature technique described in JP-A-2006-180472. Thus, for example, the transaction approver terminal 400 can change the disclosure range of the ciphertext after the signer terminal 300 has made a signature.

  That is, for example, the signature transaction generation program 312 adds a redactable signature that allows signature verification even in a state where the entire range is redacted, and receives a request or designation of disclosure of a part of attribute information from the verifier terminal 200. After that, the part of the range may be disclosed. Also, in this case, the signature transaction generation program 312 allows the verifier terminal 200 to verify in advance the redactable signature that can be verified in the state where the part of the ciphertext is disclosed to the verifier terminal 200. It may be stored in the electronic signature field.

  In step S401, the encrypted transaction generation program 111 may execute encryption using a searchable encryption or a functional encryption. In this case, the transaction approver terminal 400 is encrypted. For example, ciphertext search processing may be performed on the data field of the attribute according to the method described in JP-A-2012-123614, or the user terminal 100 may perform encryption according to the method described in JP-A-2012-133214, for example. You may control the access authority to the statement.

  The present invention is not limited to the embodiments described above, but includes various modifications. For example, the embodiments described above are described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the configurations described. In addition, part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. In addition, with respect to a part of the configuration of each embodiment, it is possible to add, delete, and replace other configurations.

  Further, each of the configurations, functions, processing units, processing means, etc. described above may be realized by hardware, for example, by designing part or all of them with an integrated circuit. Further, each configuration, function, etc. described above may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as a program, a table, and a file for realizing each function can be placed in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

  Further, control lines and information lines indicate what is considered to be necessary for the description, and not all control lines and information lines in the product are necessarily shown. In practice, almost all configurations may be considered to be mutually connected.

  100 user terminal, 101 CPU, 102 auxiliary storage device, 103 memory, 110 encrypted transaction generation program, 200 verifier terminal, 212 verification program, 300 signer terminal, signature transaction generation program, 400 transaction approver terminal, 411 transaction approval Program, 900 User Information Table

Claims (10)

A user management device,
Including processor and memory,
The memory is
A first decryption key that decrypts the information encrypted by the first encryption key;
It holds identification information for identifying a user, encrypted attribute information which is attribute information of the user encrypted with a second encryption key, and transaction data indicating reference information for referring to the encrypted attribute information. And
The reference information includes a second decryption key encrypted with the first encryption key.
The second decryption key is a key for decrypting information encrypted by the second encryption key.
The processor is
Acquiring the second decryption key included in the reference information using the first decryption key;
Decrypting the encrypted attribute information using the second decryption key to obtain attribute information of the user;
Generating a digital signature when the acquired attribute information satisfies a predetermined condition;
A user management apparatus which outputs signature transaction data including the identification information and the generated electronic signature. The user management apparatus according to claim 1, wherein
The transaction data is data received by the processor from a computer included in a plurality of computers constituting the dispersion ledger,
The user management device, wherein the processor outputs the signature transaction data to the plurality of computers. The user management apparatus according to claim 2, wherein
The transaction data is data generated by a user terminal,
The user management apparatus, wherein the first encryption key is a common key of the user terminal. The user management apparatus according to claim 1, wherein
The first encryption key is a public key of the user management device,
The user management device, wherein the first decryption key is a secret key of the user management device. The user management apparatus according to claim 1, wherein
The transaction data includes a plurality of types of encryption attribute information encrypted with different encryption keys,
The user management apparatus, wherein the plurality of types of attribute information include encrypted attribute information encrypted with the second encryption key. A user management method by a user management apparatus, comprising:
The user management device is
A first decryption key that decrypts the information encrypted by the first encryption key;
It holds identification information for identifying a user, encrypted attribute information which is attribute information of the user encrypted with a second encryption key, and transaction data indicating reference information for referring to the encrypted attribute information. And
The reference information includes a second decryption key encrypted with the first encryption key.
The second decryption key is a key for decrypting information encrypted by the second encryption key.
The user management method is
The user management device is
Acquiring the second decryption key included in the reference information using the first decryption key;
Decrypting the encrypted attribute information using the second decryption key to obtain attribute information of the user;
Generating a digital signature when the acquired attribute information satisfies a predetermined condition;
A user management method for outputting signature transaction data including the identification information and the generated electronic signature. The user management method according to claim 6, wherein
The transaction data is data received by the user management apparatus from a computer included in a plurality of computers configuring a dispersion ledger,
The user management method, wherein the user management apparatus outputs the signature transaction data to the plurality of computers. The user management method according to claim 7, wherein
The transaction data is data generated by a user terminal,
The user management method, wherein the first encryption key is a common key of the user terminal. The user management method according to claim 6, wherein
The first encryption key is a public key of the user management device,
The user management method, wherein the first decryption key is a secret key of the user management apparatus. The user management method according to claim 6, wherein
The transaction data includes a plurality of types of encryption attribute information encrypted with different encryption keys,
The user management method, wherein the plurality of types of attribute information include encrypted attribute information encrypted with the second encryption key.

Images