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

Description

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

Distributed ledger technology (or blockchain) is a technology that replaces transactions that have been carried out via reliable centralized institutions 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 settlement transactions using a virtual currency called Bitcoin (registered trademark, hereinafter the same) without the need for a centralized authority such as a bank. In Bitcoin, after a node called a miner determines the validity of transaction data (hereinafter, also referred to as a transaction) on a P2P network, a confirmation process is performed by calculating a specific hash value called a proof of work. The confirmed transactions are grouped into one block and described in a distributed ledger called a blockchain (hereinafter, also referred to as BC).

Furthermore, in recent years, based on the BC implemented in Bitcoin, various derivative technologies for BC and distributed ledger have been proposed and continue to evolve. The main features of the current BC are: (1) In transactions between participants on the BC network, the transaction is finalized by consensus building and approval by the participants (voluntary or specific) rather than the centralized authority. 2) Collect multiple transactions as blocks, record them in a distributed ledger in a string, and apply hash calculation to consecutive blocks to make it difficult to tamper with. (3) All participants share the same ledger data. By doing so, it may be possible for all participants to confirm the transaction.

Due to the above characteristics, such distributed ledger technology such as BC has the financial field, IoT (Internet of Things), etc. as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts. Is being studied for application in a wide range of fields. By using a platform that provides a distributed ledger (hereinafter referred to as a distributed ledger platform), information can be shared among multiple entities (for example, consortiums in a specific industry or multiple companies related to the supply chain) without management by a centralized authority. And can make transactions. Hereinafter, a network composed of participants (participant's nodes) participating in the distributed ledger is also referred to as a blockchain network.

The distributed ledger is not only a simple virtual currency transaction such as Bitcoin, but also system logic as well as (transaction) data in the distributed ledger so that it can be applied to complicated transaction conditions and various applications. , Also manages business logic. These logics are called smart contracts (hereinafter, also referred to as SCs).

In addition, there is a technology related to a distributed ledger platform having an SC execution function. In the distributed ledger platform, transactions (hereinafter, also referred to as TX) are accepted while forming an agreement between nodes at a predetermined agreement level, and each node executes TX to share information (ledger) on multiple nodes. .. In addition, these nodes have a smart contract (SC) execution function that executes predetermined logic for TX.

In order to put a system constructed by using these distributed ledger technologies (hereinafter referred to as a distributed ledger system) into production, user management and the like are performed in the same manner as a conventional system (for example, a Web system including a Web server and a DB server). System operation management is required (for example, including backup and restore of ledger, service stoppage, etc.). Japanese Unexamined Patent Publication No. 2006-180472 (Patent Document 1) describes an electronic signature method implemented in user management in a conventional system. Specifically, in this publication, "an electronic image is divided into a plurality of components, feature values of each component are calculated, and a signature is generated from the combination of the feature values. The component is deleted. When this is done, the data is replaced with the replacement data prepared for each component in advance, and only the feature value is saved. At the time of verification, the saved feature value is used for the replaced component, and the other feature values calculated again are used for verification. A signature is generated and compared with the signature given to the electronic image. "(See summary).

Japanese Unexamined Patent Publication No. 2006-180472

On the other hand, in the distributed ledger system, a BC network is constructed and operated by forming a consortium or the like by a plurality of entities. In other words, the distributed ledger system is configured across multiple organizations. For such a distributed ledger system, as the operation management method of the conventional system, the first method in which all the nodes are operated and managed by a single operator, and the operator of each node (for example, the ownership of the node of each organization). It is conceivable that there is a second method in which the person) manages the operation individually.

When the first method is used, there is a problem that the operation is centralized and the strength of decentralization, which is a feature of the BC system, is diminished. In addition, the first method cannot support multi-vendor operations. When the second method is used, there is a problem that it cannot be operated with the same arrangement and timing because the administrator and the policy are different for each organization. In particular, when using a consortium-type service that spans multiple entities, the issue is which entity 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 implement strict user management and user authentication in the existing system as it is and to share it with the entire consortium. Is. Therefore, it is difficult to apply the user management using the electronic signature as described in Patent Document 1 to the distributed ledger system as it is.

As a simple solution to this problem, a user management system is built on the smart contract of the distributed ledger, and the information necessary for the service such as user ID, user attribute information, and authentication information is described in it, and the entire consortium By sharing user information, it is possible to realize user management even under decentralized authority.

However, for example, user attribute information (for example, age, company name, and deposit amount) may be sensitive information and should be disclosed only to the consortium entity with legitimate access authority. is there. In other words, when managing and operating user information on a distributed ledger in a decentralized environment, it is necessary to appropriately control access to that information.

In order to solve the above problems, one aspect of the present invention adopts the following configuration. A user management device including a processor and a memory, the memory of which is a first decryption key for decrypting information encrypted with a first encryption key, identification information for identifying a user, and a second encryption key. The encryption attribute information which is the attribute information of the user encrypted in the above and the transaction data indicating the reference information for referring to the encryption attribute information are held, and the reference information is the first encryption. The second decryption key includes the second decryption key encrypted with the key, the second decryption key is a key for decrypting the information encrypted by the second encryption key, and the processor is the first decryption key. The second decryption key included in the reference information is acquired, the encryption attribute information is decrypted using the second decryption key, the attribute information of the user is acquired, and the acquired attribute information is acquired. A user management device that generates an electronic signature when the attribute information satisfies a predetermined condition and outputs signature transaction data including the identification information and the generated electronic signature.

According to one aspect of the present invention, in a decentralized environment such as a distributed ledger, user information with appropriate access control is managed without installing a specific user administrator and an administrator terminal. be able to.

Issues, configurations and effects other than those described above will be clarified by the description of the following embodiments.

It is a block diagram which shows an example of the structure of the user management system in Example 1. FIG. It is a block diagram which shows an example of the hardware composition of the user terminal in Example 1. FIG. It is a sequence diagram which shows an example of the pre-key distribution processing in Example 1. FIG. It is a sequence diagram which shows an example of the user information registration processing, signature processing, and verification processing in Example 1. This is an example of the data format of the user information table in the first embodiment. This is an example of the data format of the encrypted transaction in the first embodiment. This is an example of the data format of the query transaction in the first embodiment. This is an example of the data format of the encrypted data in the first embodiment. It is an example of the data format of the signature transaction in Example 1. This is an example of the data format of the encrypted data in the first embodiment. It is a flowchart which shows an example of the generation process of the encryption transaction in Example 1. FIG. It is a flowchart which shows an example of the signature transaction generation processing in Example 1. FIG. This is another example of the data format of the user information table in the first embodiment. This 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 common configurations in each figure.

When the user management system of the present embodiment manages and operates user information on the distributed ledger in a decentralized environment, the user terminal registers the encrypted attribute information in the distributed ledger. Further, the user management system encrypts the key used for encryption with the public key of the signer terminal and registers it in the distributed ledger. Further, after the signer terminal receiving the request from the user terminal confirms the attribute information, an electronic signature is generated in the encrypted attribute information and the signature is registered in the distributed ledger. 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 ledger, and verifies that the attribute information has been confirmed by the signer terminal. The verifier terminal does not necessarily require a centralized authority because it judges the success or 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 send and receive information to and from each other via the network 500.

The user terminal 100 requests the registration of user information in the distributed ledger of the transaction approver terminal 400. The user terminal 100 has a public key / private key pair generation program 110 and an encryption 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 digitally signs the user information on the distributed ledger 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 distributed ledger and transaction verification and approval processing, and updates the state information (user information table 900 in this embodiment) held by itself 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. Since the hardware configurations of the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400 are the same as the hardware configurations of the user terminal 100, for example, the description thereof will be omitted. The user terminal 100 is, for example, by a computer in which a CPU 101, an auxiliary storage device 102, a memory 103, a display device 105, an input / output interface 106, and a communication interface 107 are connected via an internal signal line 104. It is composed.

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 invariant program (for example, BIOS) and the like. The RAM is a high-speed and volatile storage element such as a DRAM (Dynamic Random Access Memory), 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 a program executed by the CPU 101 and data used when executing the program. .. 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, etc. are connected to receive input from an operator, a display device, a printer, etc. are connected, and an interface to output a program execution result in a format visible to the operator. ..

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

The program executed by the CPU 101 is provided to the user terminal 100 via a removable medium (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. Therefore, the user terminal 100 may have an interface for reading data from removable media.

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

For example, the CPU 101 functions as a public key / private key pair generator by operating according to the public key / private key pair generation program 110 loaded in the memory 103, and generates an encrypted transaction loaded in the memory 103. By operating according to the program 111, it functions as an encrypted transaction generator. The same applies to the relationship between the program and the CPU in other terminals.

FIG. 5 is a diagram showing an example of a user information table 900 for user management on the distributed ledger held by the transaction approver terminal 400. The user information table 900 includes, for example, a user name field, an attribute field, a referrer field, and an electronic signature field. A detailed description of each column will be described later together with the processing shown in FIG. In this embodiment, the user name is an example of information that uniquely identifies the user.

FIG. 3 is a sequence diagram showing an example of a pre-key distribution process executed between 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 a public key "pk-user" and a private key corresponding to the public key "sk-user" (S301). Similarly, the public key / private key pair generation program 210 of the verifier terminal 200 generates a public key "pk-verifier" and a private key corresponding to the public key "sk-verifier". (S302).

Similarly, the public key / private key pair generation program 310 of the signer terminal 300 generates a public key "pk-signer" and a private key corresponding to the public key "sk-signer". (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 corresponding to the public key "sk-transaction approver". Is generated (S304). In creating the public key / private key pair in this embodiment, for example, a method such as RSA cryptography or elliptic curve cryptography is used.

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-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 uses the public key "pk-signer (D300)" generated in step S303 as the user terminal 100, the verifier terminal 200, and the transaction approver terminal 400. Is transmitted to (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. Then (S314 to S316), the pre-key distribution process is completed. By the above processing, a public key and a private key are generated on the user terminal 100, the verifier terminal 200, the signer terminal 300, and the transaction approver terminal 400, and the public key is distributed to each other.

FIG. 4 is a sequence diagram showing an example of user information registration, signature, and verification processing in a user management system. In the following example, the user name of the user terminal 100 is "Alice", and the age "25 years old" is registered as the attribute information of Alice. In this embodiment, the user terminal 100 registers the user information in the distributed ledger, the signer terminal 300 confirms the user information, and then electronically signs the user information on the distributed ledger, and the verifier terminal 200 performs the user information. An example of a process for verifying user information.

First, the encrypted transaction generation program 111 of the user terminal 100 executes an encrypted transaction generation process, generates an encrypted transaction to be registered in the distributed ledger (S401), and uses the generated encrypted transaction as all transaction approver terminals. It is transmitted to 400 (S402). The encrypted transaction generation program 111 does not necessarily have to transmit the completed encrypted transaction to all transaction approver terminals 400, for example, a predetermined policy, an instruction input to the user terminal 100, or the like. Therefore, it may be transmitted only to some transaction approver terminals 400.

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

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

Returning to the description of FIG. Next, the transaction approval program 411 of the transaction approver terminal 400 that has received the encrypted transaction executes the 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 unsuccessful, the transaction approval program 411 discards the received encrypted transaction in step S403. As the transaction approval processing method, the Proof of Work method may be used, the PBFT (Practical Byzantine Facility Toleance) method may be used, or other transaction approval technology for distributed ledgers may be used. You may.

Next, the query generation program 311 of the signer terminal 300 generates a query transaction in the query generation process for acquiring the user information registered in the distributed ledger (S404), and approves all the generated query transactions. It is transmitted to the user terminal 400 (S405). The query generation program 311 of the signer terminal 300 does not necessarily have to send the completed query transaction to all transaction approver terminals 400, and is input to, for example, a predetermined policy or the signer terminal 300. It may be transmitted only to some transaction approver terminals 400 according to the instructions and the like.

The query generation program 311 periodically executes the processes of steps S404 to S405, for example. Further, when the signer terminal 300 is notified that the user terminal 100 has transmitted the encrypted transaction to the distributed ledger and the signer terminal 300 receives the notification, the query generation program 311 may perform steps S404 to S405. Processing may be performed.

If the user's identity verification information (for example, user attribute information, user identification information, etc.) of the user terminal 100 is stored in advance in the auxiliary storage device of the signer terminal 300, the user's information may be used. Identity verification may be performed. Specifically, for example, the signer who is the user of the signer terminal 300 acquires the identity verification information by confirming the identity of the user of the user terminal 100 by telephone or face-to-face. The signer terminal 300 accepts the 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 information and the user information stored in advance in the auxiliary storage device of the signer terminal 300 match. If not, for example, an error is output to the display device of the signer terminal 300 and the user terminal 100. The signer who is a user of the signer terminal 300 may directly input the result of the match determination into the signer terminal 300 via an input device or the like.

FIG. 7 is a diagram showing an example of the data format of the query transaction generated in step S404. In the query transaction of FIG. 7, SELECT WHERE user name = [Alice] is described. That is, the query transaction of FIG. 7 is a query transaction for acquiring a record related to the user name "Alice" of the user information table 900 on the distributed ledger. In step S404, a query transaction by another query method may be generated.

Returning to the description 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 distributed ledger for the encrypted data corresponding to the received query transaction, and returns the encrypted data to the signer terminal 300. (S406). If the encrypted data corresponding to the query transaction does not exist in the user information table 900, the transaction approval program 411 returns an error to the signer terminal 300.

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

Returning to the description of FIG. Next, the signature transaction generation program 312 of the signer terminal 300 that has received the encrypted data uses the received encrypted data as the private key "sk-signer" generated in the public key / private key pair generation process in step S303. , And verify the plaintext attribute information obtained as a result of the decoding (S407).

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

If the verification result is successful in step S407, the signature transaction generation program 312 generates an electronic signature for the encrypted data using the private key "sk-signer" generated in step S304, and the generated electronic signature is used. A signature transaction including a signature is generated, and the generated signature transaction is transmitted to the transaction approver terminal 400 (S408). The signature transaction generation program 312 does not necessarily have to send the generated signature transaction to all transaction approver terminals 400, and in accordance with, for example, a predetermined policy or an instruction input to the signer terminal 300. , It may be transmitted only to some transaction approver terminals 400.

FIG. 9 is a diagram showing an example of a data format of a signature transaction. FIG. 9 is an example of a signature transaction generated when the verification result for the attribute information whose user name value is “Alice” is successful. In the electronic signature field, the [Signed by signer], which is the value of the electronic signature generated by using the "sk-signer" which is the private key of the signer terminal 300, is stored.

In the example of the signature transaction of FIG. 9, the attribute column and the referrer column are blank. For example, the attribute information (Alice's encrypted attribute information [Enc (K, 25 years old)] or Alice is entered in the attribute column. Unencrypted attribute information [25 years old]) may be stored. Further, the value of the electronic signature field [Signed by signer] can be verified by using the signer's public key "pk-signer". For signature generation and signature verification, for example, an existing method such as RSA signature may be used.

Returning to the description of FIG. Next, the transaction approval program 411 of the transaction approver terminal 400 that has received the signature transaction executes the transaction approval process (S409). If the approval result is successful, 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 distributed ledger in step S409. To do. On the other hand, if the approval result is unsuccessful, 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 the user information registered in the distributed ledger (S410), and generates the generated query transaction. It is transmitted to the transaction approver terminal 400 (S411). The query generation program 211 of the verifier terminal 200 does not necessarily have to send the generated query transaction to all transaction approvers terminals 400, and is input to, for example, a predetermined policy or the verifier terminal 200. It may be transmitted only to some transaction approver terminals 400 according to the instructions and the like.

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 periodically executes the processes of steps S410 to S411, for example. Further, the verifier terminal 200 may be notified that the user terminal 100 has transmitted the encrypted transaction to the distributed ledger, and the query generation program 211 may perform the processes of steps S410 to S411 when the notification is received.

Next, the transaction approval program 411 of the transaction approver terminal 400 that received the query transaction transmitted in step S411 searches the user information table 900 for the encrypted data corresponding to the received query transaction, and the verifier terminal. Reply to 200 (S412). If the encrypted data corresponding to the query transaction does not exist in the user information table 900, the transaction approval program 411 returns an error 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 encrypted data for a query transaction whose user name is "Alice" in the example of FIG. 9, and the record of the user information table 900 whose user name value is "Alice" is the encrypted data. Since the signing transaction was received in step S408, the electronic signature field of the record in which the user name of the user information table 900 is [Alice] is updated. Therefore, in the encrypted data of FIG. 8, the electronic signature field was blank, but in the encrypted data of FIG. 10, [Signed by signer] is stored in the electronic signature field.

Returning to the description of FIG. Next, the verification program 212 of the verifier terminal 200, which has received the encrypted data from the transaction approver terminal 400, decrypts the received encrypted data using the private key “sk-verifier” generated in step S302. Then, the decrypted plaintext attribute information is verified (S413).

In the verification of the attribute information in step S413, the verification program 212 determines whether or not the plaintext attribute information satisfies a predetermined condition (for example, when the attribute information indicates an age, the age is predetermined). Verify whether it is included in the range (for example, 20 years old or older and 60 years old or younger). Further, 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 unsuccessful, the verification program 212 outputs an error to the display device or the like of the verifier terminal 200 to end the process, and if the verification result is successful, 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 terminated.

The user management system of this embodiment manages user information with appropriate access control even on the distributed ledger by the process shown in FIG. 4 without installing a specific user administrator and an administrator terminal. can do.

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

Next, the encryption 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 encryption transaction generation program 111 encrypts the age [25 years old], which is the plaintext attribute value of "Alice", by using the common key cryptographic algorithm and the common key "K". [Enc (K, 25 years old)] is generated and output (S1103).

Next, the encrypted transaction generation program 111 sets a referrer 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 referenceable persons will be described. In step S1104, the encrypted transaction generation program 111 receives the input of the information indicating the referable person via, for example, an input device or the like.

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

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

FIG. 12 is a flowchart showing an example of details of the signature transaction generation process in step S407. Hereinafter, the signature transaction generation process for the 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 the decryption process (S1202). In step S1202, the signature transaction generation program 312 sets the [Pub-Enc (pk-signer, K)] stored in the referenceable person column of the encrypted data to the private key "sk-signer" of the signer terminal 300. Decrypt with "" to obtain the common key "K".

Next, the signature transaction generation program 312 decrypts the encrypted data attribute [Enc (K, 25 years old)] using the common key “K” acquired in step S1202, and outputs the plaintext 25 years old. , Executes the verification process of the attribute which is the plaintext (S1203). As the verification process, the signature transaction generation program 312 succeeds in verification when, for example, the attribute in plain text and the attribute of the user (here, "Alice") held by the signer terminal 300 in advance match. Judgment is made, and if they do not match, it is judged that the verification has failed. Further, in the verification process, the user of the signer terminal 300 confirms the identity 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 then obtains the verification result. , May be input to the signer terminal 300.

In the verification process, not only the attribute information but also the information that identifies the user can be used. That is, if the encrypted data contains information that identifies the user, 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), and the signature transaction is generated. End the process.

When the signature transaction generation program 312 determines that the verification result is unsuccessful (S1203: verification success), the signature transaction generation program 312 executes the signature generation process (S1205). In step S1205, the signature transaction generation program 312 sets the digital signature algorithm and the private key "sk-signer" for the user name [Alice] and the attribute: [Enc (K, 25 years old)], which are the target data of the digital signature. To generate an electronic signature [Signed by signer] and output an 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 process. ..

FIG. 13 is a diagram showing another example of the user information table 900. The user information table 900 of FIG. 5 has only one attribute column, but the user information table 900 of FIG. 13 has a plurality of attribute columns (attribute 1 column, ..., Attribute n column). Allows you to store multiple types of attributes.

FIG. 14 is a diagram showing another example of the user information table 900. 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 uppermost record of the user information table 900 of FIG. 14, the attribute 1 column is Enc ₁ (K ₁ , 25 years old), ..., The attribute n column is Enc _n (K _n , female). As described above, the encryption is performed using a common key / public key encryption method and / or an encryption key that are different for each attribute.

Further, for example, a different referrer may be set for each attribute in the user information table 900. That is, the user terminal 100 may set the access authority for each attribute by registering a different decryption key for each referrer in the data field of the referrer column.

Further, as a method for further encrypting the attribute, multiple encryption such as encrypting the ciphertext with another encryption method may be used. Specifically, for example, when the plaintext age "25 years old" is encrypted with the first common key, the ciphertext "20 years old or older" is generated, and the ciphertext "20 years old or older" is encrypted with the second common key. Suppose that encryption produces a ciphertext that does not suggest age. The user terminal 100 is, for example, a referenceable person who can acquire the first common key and the second common key, a referenceable person who can acquire only the second common key, and the first common key and the second common key. The access level for the same attribute information can be set by determining the referrer who cannot acquire any of the common keys.

Further, in step S407, the signature transaction generation program 312 may generate a signature at this time by using the black-painted signature technique described in Japanese Patent Application Laid-Open No. 2006-180472. Thereby, for example, the transaction approver terminal 400 can change the disclosure range of the ciphertext after the signer terminal 300 signs.

That is, for example, the signature transaction generation program 312 assigns a black-painted signature that enables signature verification even when the entire range is black-painted, and receives a request or designation for disclosure of some attribute information from the verifier terminal 200. After that, the partial scope may be disclosed. Further, in this case, the signature transaction generation program 312 enables the verifier terminal 200 to verify the signature in advance so that the signature can be verified with the part of the ciphertext disclosed to the verifier terminal 200. It may be stored in the electronic signature line.

Further, in step S401, the encryption transaction generation program 111 may execute encryption using a searchable encryption or a functional encryption, and in this case, the transaction approver terminal 400 is encrypted. The ciphertext search process may be performed on the attribute data field by, for example, the method described in Japanese Patent Application Laid-Open No. 2012-123614, and the user terminal 100 may perform encryption by 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 above-described examples, and includes various modifications. For example, the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the described configurations. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to add / delete / replace a part of the configuration of each embodiment with another configuration.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored 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.

In addition, the control lines and information lines indicate those that are considered necessary for explanation, and do not necessarily indicate all the control lines and information lines in the product. In practice, it can be considered that almost all configurations are interconnected.

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

Claims (10)

It is a user management device
Including processor and memory
The memory is
The first decryption key that decrypts the information encrypted by the first encryption key,
It holds identification information that identifies the user, encryption attribute information that is the attribute information of the user encrypted with the second encryption key, and transaction data that indicates 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 processor
The second decryption key included in the reference information is obtained by using the first decryption key.
The encryption attribute information is decrypted using the second decryption key to acquire the attribute information of the user.
When the acquired attribute information satisfies a predetermined condition, an electronic signature is generated.
A user management device that outputs signature transaction data including the identification information and the generated electronic signature. The user management device according to claim 1.
The transaction data is data received by the processor from a first computer included in a plurality of computers constituting the distributed ledger.
The processor is a user management device that outputs the signature transaction data to the first computer. The user management device according to claim 2.
The transaction data is data generated by a user terminal and is
The first encryption key is a user management device which is a common key of the user terminal. The user management device according to claim 1.
The first encryption key is a public key of the user management device.
The first decryption key is a user management device which is a private key of the user management device. The user management device according to claim 1.
The transaction data includes a plurality of types of encryption attribute information encrypted with different encryption keys.
The plurality of types of encryption attribute information is a user management device including encryption attribute information encrypted with the second encryption key. It is a user management method using a user management device.
The user management device is
The first decryption key that decrypts the information encrypted by the first encryption key,
It holds identification information that identifies the user, encryption attribute information that is the attribute information of the user encrypted with the second encryption key, and transaction data that indicates 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 user management method is
The user management device
The second decryption key included in the reference information is obtained by using the first decryption key.
The encryption attribute information is decrypted using the second decryption key to acquire the attribute information of the user.
When the acquired attribute information satisfies a predetermined condition, an electronic signature is generated.
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.
The transaction data is data received by the user management device from the first computer included in a plurality of computers constituting the distributed ledger.
The user management method is a user management method in which the user management device outputs the signature transaction data to the first computer. The user management method according to claim 7.
The transaction data is data generated by a user terminal and is
The first encryption key is a user management method, which is a common key of the user terminal. The user management method according to claim 6.
The first encryption key is a public key of the user management device.
The first decryption key is a user management method, which is a private key of the user management device. The user management method according to claim 6.
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 encryption attribute information includes encryption attribute information encrypted with the second encryption key.

Images