JP6976405B2 - Access control system and its programs - Google Patents

Description

The present invention relates to an access control system, a program thereof, and the like.

In recent years, an encryption-based control method has attracted attention as an access control method. In the encryption-based access control method, data is encrypted so that only the entity to which access is permitted can decrypt the data, and the authority of the entity is verified based on whether or not the data can be decrypted (for example, Non-Patent Document 1). ..

S. Kamara and K. Lauter, “Cryptographic cloud storage,” in Proc. FC 2010, Jan. 2010, pp. 136-149

In the conventional encryption-based access control method such as Non-Patent Document 1, a central server such as a certificate authority (CA) issues an encryption key or a decryption key for access control. Therefore, in a system managed by a conventional encryption-based access control method, the reliability of the system depends on the reliability of the central server. In such a system, if the central server is hijacked, all the keys issued based on the reliability of the central server become unreliable, so the central server is called a single point of failure (SPOF). turn into. It would be very expensive to increase the security level of the central server to prevent this.

Therefore, in view of the above circumstances, the present invention aims to improve fault tolerance in encryption-based access control.

The program according to the present invention is the first key for indicating the access authority of the first user to the computer that can access the distributed database in which the transaction is managed, and is not associated with the first user in the distributed database. Acquisition means for acquiring the first key, verification means for verifying the first key, sharing means for sharing information about the first key with one or more second user computers accessible to a distributed database, first key. And a generation means that generates a first transaction requesting approval of the use of the first key, including the information of the first user and the digital signature of the first user, and the first transaction is digitally signed by one or more second users. It functions as a transmission means for transmitting a first transaction to one or more second user computers in order to be registered in a distributed database.

The program of the present invention can be installed or loaded in a computer by downloading through various recording media such as an optical disk such as a CD-ROM, a magnetic disk, and a semiconductor memory, or via a communication network or the like.

Further, in the present specification and the like, the “part” does not simply mean a physical configuration, but also includes a case where the function of the configuration is realized by software. Further, the function of one configuration may be realized by two or more physical configurations, or the function of two or more configurations may be realized by one physical configuration.

According to the present invention, fault tolerance can be improved in encryption-based access control.

It is a block diagram of the access management system in embodiment of this invention. It is a figure which shows an example of the functional block of a node in embodiment of this invention. It is a figure which shows an example of the transaction data structure in embodiment of this invention schematically. It is a figure which shows an example of the transaction data structure in embodiment of this invention schematically. It is a figure which shows an example of the transaction data structure in embodiment of this invention schematically. It is a flowchart which shows an example of the process flow of a node in embodiment of this invention. It is a figure which shows an example of the functional block of a node in embodiment of this invention. It is a flowchart which shows an example of the process flow of a node in embodiment of this invention. It is a figure which shows typically the mechanism of the user authentication in embodiment of this invention. It is a figure which shows an example of the hardware composition of the terminal in embodiment of this invention.

[First Embodiment]
Hereinafter, one of the embodiments of the present invention will be described in detail. It should be noted that the following embodiments are examples for explaining the present invention, and the present invention is not limited to the embodiments thereof. Further, the present invention can be modified in various ways as long as it does not deviate from the gist thereof. Further, those skilled in the art can adopt an embodiment in which each element described below is replaced with an equal one, and such an embodiment is also included in the scope of the present invention.

<1. Overview of system configuration>
FIG. 1 shows an example of the system configuration of the access control system 1 according to the present invention. The access management system 1 manages operations on keys used for encryption-based access control. The key is used as information indicating the user's access authority in encryption-based access control. In the present embodiment, the keys used in the access control system 1 are the public key and the private key in the public key cryptosystem. However, the key encryption method used in the access management system 1 is not limited to the public key encryption method, and may be, for example, a common key encryption method.

Operations on keys include key generation, renewal, or revocation. In the access management system 1, when a certain user (operator) operates the key, another one or more users (approvers) approve the key. Here, "approving the operation on the key" means approving the key to be used when the operation on the key is generated / updated, and when the operation on the key is revoked, the revoked operation. Is to approve. When one or more approvers approve the operation on the key, the users can mutually guarantee the reliability of the key. As a result, in the access management system 1, even if the reliability of some approvers is impaired, the reliability of the entire system can be continued based on the reliability of other approvers.

Further, in the access management system 1, the approver does not have to be a fixed user and may be different depending on the owner of the key to be operated, and even if the owner of the key is the same, the key is assigned. A different user may become the approver for each operation of. As a result, even if the credibility of a certain approver is compromised, the scope of influence can be limited to the key approved only by the credibility-impaired approver. As a result, the reliability of the entire system can be maintained.

As shown in FIG. 1, the access management system 1 includes a plurality of nodes 10A, 10B, and 10C (hereinafter, these nodes are collectively referred to simply as "node 10") connected to a network N such as the Internet. It has a database 30. In the example of FIG. 1, three nodes are described as an example, but the number of nodes is not limited.

The network N is composed of a wireless network and a wired network. Examples of communication networks include mobile phone networks, PHS (Personal Handy-phone System) networks, wireless LAN (Local Area Network), 3G (3rd Generation), LTE (Long Term Evolution), 4G (4th Generation), and 4G (4th Generation). There are networks compliant with (registered trademark), infrared communication, WiMAX (registered trademark), wired LAN, telephone line, power line network, IEEE1394, and the like.

The node 10 is a computer connected to the network N, and a predetermined application provided by the access management system 1 is installed. The predetermined application may be installed in the node 10 in advance, or may be installed in the node 10 after the fact by downloading or the like.

Typically, the node 10 is a mobile phone, a smartphone, a PC (Personal Computer), a PDA (Personal Digital Assistants), a tablet, a wearable terminal, a server device, a game machine, or the like. The nodes 10A and 10B and the nodes 10C are connected to each other by P2P (Peer to Peer) via the network N, and constitutes a distributed ledger system. However, the node 10 may be configured so as to be accessible to the distributed ledger system, and is not necessarily limited to the mode in which the distributed ledger system is configured. Note that each node may be directly connected to P2P without going through the network N.

In the following description, the users of the nodes 10A, 10B, and 10C will be referred to as users A, B, and C, respectively. Each of the users A, B, and C is assigned a unique identifier in the access management system 1. The identifier is, for example, a unique identifier given when the user registers with the access control system 1, an e-mail address, a node identifier, an ID identified by an application installed on the node, or the like.

As an example, user A will be described as an operator, node 10A as an operation node, users B and C as approvers, and nodes 10B and 10C as approval nodes. It should be noted that the operation node and the approval node do not have to be separate nodes, and a single node may have the functions of both the operation node and the approval node. Further, the user of each node is not limited to one, and one node may be shared by a plurality of users.

In this embodiment, the database 30 is built on a storage management server connected to the network N. The database 30 is not limited to this, and may be built on a WEB server connected to the network N, for example.

In the present embodiment, each configuration of the access management system 1 will be described as an example of being connected via the network N, but the present invention is not limited to this. For example, the node 10 may be connected to a private network, and the database 30 may be connected to the private network to which the node 10 is connected via the Internet. Similarly, the node 10 may be connected via the Internet, and the database 30 may be connected to a private network that can connect to the Internet.

<2. Database 30>
Key information managed by the access management system 1 is registered in the database 30. As an example, a record in which a public key and an encrypted private key are associated with each other is registered in the database 30. In this case, it is preferable that the transaction described later includes the hash value of the public key and the encrypted private key. As will be described later, if the transaction includes the main body of the public key, the database 30 may not be present. Further, each record of the database 30 may include an identifier of a user who is the owner of the key, an ID of a transaction that operates on the registered key, information indicating the reliability of the user, and the like. The information indicating the reliability of the user is, for example, information indicating whether the user has committed fraud in the past in the access management system 1. Further, the database 30 may be configured to manage public key and private key identifiers.

<3. Node 10>
<3-1. Operation node (node 10A)>
Next, the functional configuration of the node 10A, which is an operation node, will be described with reference to FIG. FIG. 2 is a functional block diagram of the node 10A according to the present embodiment. As shown in FIG. 2, the node 10A has a storage unit 130, a key acquisition unit 111, a key verification unit 112, a transaction generation unit 114, a signature execution unit 115, and a database control unit 116. There is. Further, as shown in FIG. 2, the storage unit 130 records the private key of the user A and the distributed ledger 131. The distributed ledger 131 is a distributed database stored in a plurality of nodes 10 constituting the distributed ledger system. However, it is not necessary that all the nodes 10 have the distributed ledger 131, and only some of the nodes 10 may have the distributed ledger 131.

(1) Distributed Ledger FIGS. 3 to 5 are diagrams schematically showing a part of a transaction data structure managed by the distributed ledger 131 (an example of a distributed database). In the distributed ledger 131, blocks storing each of a plurality of transactions are recorded in a structure of a string of beads connected in a row. Although the example of FIGS. 3 to 5 shows an example in which one block has only one transaction, one block may have a plurality of transactions. Further, the transaction does not necessarily have to be stored in a block, and the transaction itself may be configured to be a string of beads.

FIG. 3 is a diagram showing an example of the structure of block 1 including a key generation transaction (an example of a first transaction) managed in the distributed ledger 131. A key generation transaction is a transaction that seeks approval of a new key that has been generated. FIG. 3 shows, as an example, a key generation transaction for approving a key (an example of a first key) generated by a user A (an example of a first user).

For example, the following data is stored in the key generation transaction.
-Data of the key generated by user A-Signature of user A-Signature of another user (also referred to as an approver, which is an example of one or more second users).

The generated key data is information that can identify the key newly used by the user A, for example, a hash value of the public key of the key pair approved in the key generation transaction. As the generated key data, instead of the hash value of the public key, the public key data itself or a unique identifier in the public key access control system 1 may be stored in the key generation transaction. The key generation transaction may also include a public key that is further generated or a private key that is encrypted with another existing public key. Further, the generated public key and private key key pair is not limited to the user A individual key pair, and may be a key pair used in the service provided by the user A.

The user A's signature is a digital signature generated using the private key of the key pair approved in the key generation transaction. In the following description, "digital signature" is also simply referred to as "signature", and "generating a digital signature using a key" is also referred to simply as "signing" or "signing".

The approver's signature is a signature generated by any number of users other than user A using their own private key when approving the generated key. In the example of FIG. 3, the key generation transaction includes the signatures of two users (users B and C), but the number of signatures of the approver may be any number of 1 or more. Further, the user who generates the signature as the approver can be designated by, for example, the user A (that is, the user who newly generates the key). In addition, the approver may be randomly selected from the users of the node 10 included in the access management system 1, or may be a user selected in advance by the administrator of the access management system 1. Further, the number of required signatures of the approver may be determined in advance by the administrator of the access management system 1, may be specified by the user A, or may be randomly determined. That is, the user selected as the approver in the key generation transaction is not fixed but indefinite.

In the present embodiment, the signature of each user is the data excluding the area where the signature is generated in the key generation transaction (that is, the data of the key generated by the user A (in the present embodiment, the public key). Hash value) ”) is used as a digest, and it is generated by encrypting the digest using its own private key.

FIG. 4 is a diagram showing an example of the structure of block B2 including a key update transaction (an example of a second transaction) managed in the distributed ledger 131. The key update transaction is a transaction for requesting approval for updating a key approved by the access management system 1 (an example of a first key) to a new key (an example of a second key). Is. FIG. 4 shows, as an example, a key update transaction when the key of user A approved in the key generation transaction shown in FIG. 3 is updated for the nth time.

For example, the following data is stored in the key update transaction.
-Hash value of the previous transaction data-Data of the updated key of user A-Signature of user A-Signature of another user (approver) In addition to the above, the key update transaction is the previous one. It may include a pointer to a transaction.

The previous transaction refers to the transaction in which the key is updated n-1st in the case of the key update transaction in which the key is updated nth time. When the key update transaction this time is the one that updates the key for the first time, the previous transaction refers to the key generation transaction. Of course, the transaction immediately before the key update transaction is also configured to include the hash value of the transaction data immediately before. In this way, every key update transaction has a data structure that is linked up to the key generation transaction. Then, the key update transaction will include the hash value of the update history of all keys from the transaction in which the key was generated to the key update transaction. By adopting such a configuration in the key update transaction, even if the transaction in the middle is tampered with, it becomes easy to detect.

The updated key data is, for example, a hash value of the updated public key approved as a new key in a key update transaction. The updated key data may be any information that can identify the new key, and may be, for example, a public key identifier. The key update transaction may further include the updated private key encrypted with the updated public key.

The signature of the user A is a signature generated by using the respective private keys before and after the update. In other words, it is a signature generated by using the secret key after the update of this time (nth time) and the secret key after the update of the previous time (n-1th time). However, if the key updated in the key update transaction is a key different from the key used for the signature of the user A itself, such as the key used in the service provided by the user A, the user A is used for the signature. It is also possible to generate a signature using a key.

The approver's signature is a signature generated by any number of users other than user A using their own private key when approving the updated key. The approver's signature is, for example, the same user's signature as the approver's signature of the key generation transaction that is the origin of the key update transaction. However, the present invention is not limited to this, and the user who signs as an approver and the number thereof may be selected by user A (key updater) for each key update transaction, or may be randomly determined. The administrator of the access management system 1 may set in advance a user to sign according to the number of updates. That is, the user selected as the approver in the key update transaction is not fixed but indefinite.

Also in the key update transaction, the signature of each user is the data excluding the area to be signed in the key update transaction (that is, "hash value of the previous transaction data" and "user A's updated key". It is generated by using the hash value of data (the hash value of the public key in this embodiment) ”) as a digest and encrypting the digest using its own private key.

FIG. 5 is a diagram showing an example of the structure of block B3 including a key revocation transaction (an example of a third transaction) managed in the distributed ledger 131. The key revocation transaction is a transaction that revokes the key generated in the access management system 1. FIG. 5 shows, as an example, a key revocation transaction that revokes the key of user A generated in the key generation transaction shown in FIG.

For example, the following data is stored in the key revocation transaction.
-Hash value of the previous transaction data-Key revocation information of user A-Signature of user A-Signature of another user (approver) In addition to the above, the key revocation transaction goes to the previous transaction. May include a pointer to.

The key revocation information of the user A is information that can identify that the key of the user A has revoked. The revocation information includes, for example, the revocation date of the key, the reason for revocation, and the like. Reasons for revocation typically include an application from the key owner (lost or stolen private key, suspension of service, etc.), as well as revocation registration by the system administrator (violation of user obligations, etc.). The revoked information may further include information that can identify the key to be revoked (for example, a public key body and an encrypted private key).

The signature of the user A is, for example, a signature generated by using the key to be revoked. However, if the key revoked in the key revocation transaction is a key different from the key used for the signature of the user A itself, such as the key used in the service provided by the user A, the user A is used for the signature. It is also possible to generate a signature using a key. If the revocation operation is performed by a user other than user A (that is, a user other than the owner of the key to be revoked), the signature of user A (key owner) may not be required. In this case, the key revocation transaction includes the revocation operator's signature instead of the user A's signature.

The approver's signature is a signature generated by any number of users other than user A using their own private key when approving the revocation of the key. The user and the number of users to sign as an approver may be the same as the signature of the approver included in the key generation transaction that originated from the key update transaction, or may be the signature of the revoked person or the administrator of the access control system 1. May be specified or may be randomly determined. That is, the user selected as the approver in the key revocation transaction is not fixed but indefinite.

Even in the key revocation transaction, the signature of each user is the data excluding the area where the signature is generated in the key update transaction (that is, the "hash value of the previous transaction data" and the "user A key revocation". It is generated by using the hash value of "information") as a digest and encrypting the digest using its own private key.

Returning to FIG. 2, the details of each functional unit of the node 10 will be described. In the following description, the key generation transaction, the key update transaction, and the key expiration transaction are collectively referred to as a simple "transaction".

(2) Key acquisition unit 111
The key acquisition unit 111 (an example of acquisition means) acquires information on the key to be operated. For example, when the operation is key generation, the key acquisition unit 111 can generate the key. The generated key is a key that is not associated with user A in the distributed ledger 131 and / or the database 30.

If the operation is a key update, the key acquisition unit 111 generates a new key after the update. The new key after the update is a key that is not associated with the user A in the distributed ledger 131 and / or the database 30. Further, the key acquisition unit 111 refers to the database 30 and acquires the key to be updated.

If the operation is a key revocation, the key acquisition unit 111 does not perform any processing. However, even in this case, the key acquisition unit 111 may acquire the key to be revoked by referring to the database 30.

When acquiring the key from the database 30, the key acquisition unit 111 can search the database 30 based on the ID of the transaction for which the key to be operated is approved or the identifier of the user A. Further, the key acquisition unit 111 may be configured to request the generation of the key from another node and acquire the key generated in the other node instead of generating the key. In this case, the other node that generates the key is preferably, for example, the management node of the access management system 1.

(3) Key verification unit 112
The key verification unit 112 (an example of the verification means) verifies whether at least the key newly used by the user A among the keys acquired by the key acquisition unit 111 functions normally. For example, the key verification unit 112 verifies whether or not the data encrypted by one key can be decrypted by the other key for the key pair generated by the key acquisition unit 111 or the key pair requested to be generated by another node. conduct.

(4) Transaction generator 113
The transaction generation unit 113 (an example of the generation means) generates a transaction related to a key operation. The generation process of each transaction configuration will be specifically described.

First, the transaction generation unit 113 generates a hash value as key data from, for example, a public key verified by the key verification unit 112 using a predetermined hash function. The transaction generation unit 113 may use the public key identifier as the key data. When the transaction includes an encrypted private key, the transaction generation unit 113 encrypts the private key by using the public key corresponding to the private key or another existing public key.

Next, when the transaction to be generated is a key update transaction or a key expiration transaction, the transaction generation unit 113 generates a hash value of the previous transaction. The transaction immediately before the transaction generated this time is the transaction in which the key to be operated (updated / revoked) is approved. Therefore, first, the transaction generation unit 113 specifies the transaction ID in which the key to be operated is approved. For example, the transaction generation unit 113 may be configured such that the transaction ID is specified by the user A, or the transaction ID is specified by the user A and the key to be updated is specified, the database 30 is referred to, and the transaction corresponding to the specified key is received. It may be configured to specify the ID. When the transaction ID is specified, the transaction generation unit 113 refers to the distributed ledger 131, acquires the transaction corresponding to the specified transaction ID, and calculates the hash value of the transaction.

If the transaction to be generated is a key revocation transaction, the transaction generation unit 113 further generates revocation information. The revocation information can be generated, for example, by accepting an input from the user A.

Finally, the transaction generation unit 113 assigns a unique transaction ID in the network N and generates a transaction.

(5) Signature execution unit 114
The signature execution unit 114 signs the transaction using the user A's signature key. As an example, the signature execution unit 114 calculates the hash value of the data excluding the area where the signature is stored in the transaction generated by the transaction generation unit 113, and generates a digest. Then, the signature execution unit 114 signs the generated digest by encrypting it using the private key of the user A. The private key used for signing here is, for example, the generated secret key in the case of a key generation transaction, the secret key before and after the update in the case of a key update transaction, and the secret key to be revoked in the case of a key revocation transaction. Is. It should be noted that the key operated in the transaction and the key for generating the signature do not necessarily have to be a pair. For example, if the public key operated in the transaction is different from the public key corresponding to the private key for user A's signature, the signature execution unit 114 may use the user A's existing signature key (that is, in the transaction). A signature is generated by encrypting the generated digest using a key that is different from the key to be operated.

(6) Transmitter 115
The transmission unit 115 (an example of the transmission means) transmits the transaction signed by the signature execution unit 115 to the node of the approval request destination. At this time, the transmission unit 115 sets the identifier of another user (approver) who requests the transaction for approval (that is, requests the signature) as the destination for the approval request. For example, the transmission unit 115 may be configured to accept the designation of the approver of the approval request destination from the user A of the node 10A, or may be configured to set a pre-determined approver from the administrator of the access management system 1. , The configuration may be set by randomly selecting from the users of the access management system 1.

When the transmission unit 115 sends the transaction to the approval request destination, the public key that can decrypt the signature made by the signature execution unit 115 (that is, the newly generated public key, the updated public key, and the invalidated one). The target public key) may also be transmitted. The transmission unit 115 can also transmit the transaction to the entire network N.

(7) Database control unit 116
The database control unit 116 (an example of the sharing means) shares the key verified by the key verification unit 112 with other nodes (nodes 10B and 10C) constituting the distributed ledger system. As an example, the database control unit 116 registers the key verified by the key verification unit 112 in the database 30. Specifically, when the operation on the key is "generate", the database control unit 116 adds a new record to the database 30 and adds a public key and a private key encrypted with the public key. To register.

When the operation for the key is "update", the database control unit 116 refers to the database 30 and extracts a record corresponding to the key to be updated, and the extracted record contains the updated public key and the relevant key. Add the private key encrypted with the public key. The database control unit 116 may be configured to replace the public key and the encrypted private key before the update with the public key and the encrypted private key after the update.

When the operation on the key is "revocation", the database control unit 116 refers to the database 30 and deletes the record corresponding to the key to be revoked. The database control unit 116 may be configured to add revocation information to the extracted records instead of deleting the records.

When the database control unit 116 registers the key in the database 30, the database control unit 116 registers the identifier of the transaction generated by the transaction generation unit 114 in association with the key (hereinafter, also referred to as “transaction ID”) in the database 30. It is preferable to keep it.

The method in which the database control unit 116 shares the key with another node may be a method of registering the key in the database 30 or a method of directly transmitting the key to the other node.

Further, in the present embodiment, the database control unit 116 registers the verified key in the database 30 before the transmission unit 115 transmits the transaction. In this case, the database control unit 116 rolls back the registered contents if the transmitted transaction is not approved by the approver. However, the timing of the registration process is not limited to this, and the database control unit 116 performs the registration process of the verified key in the database 30 in the database control unit 116 when the signing of the transaction by the approver is completed. It may be configured to be performed. In this case, it is preferable that the transaction includes the public key itself capable of decrypting the signature of the user A, or when the transmission unit 115 transmits the transaction, the database control unit 116 also transmits the public key.

(8) Processing Flow With reference to FIG. 6, the processing flow when the node 10A operates on the key will be described. FIG. 6 is a flowchart showing an example of the processing flow of the node 10A.

First, the key acquisition unit 111 acquires the key to be operated (S11). The key acquisition unit 111 acquires the key to be operated by generating a key or searching from the database 30 according to the operation content.

Next, the key verification unit 112 verifies whether or not the acquired key functions normally (S12). If the key does not function normally (S13: NO), the node 10A ends the process. At this time, the node 10A may be configured to notify the administrator of the access management system 1.

When the key functions normally (S13: YES), the transaction generation unit 113 generates a transaction. When the signature execution unit 114 signs the generated transaction (S15), the transmission unit 115 sets the approval request destination and transmits the transaction (S16). On the other hand, when the key functions normally (S13: YES), the database control unit 116 registers the verified key in the database 30 (S17). The context of the processing of S17 and the processing of S14 to S16 is arbitrary.

If the processing of S17 is performed before the processing of S16, the database control unit 116 rolls back the database 30 and registers the key when the transaction transmitted by the transmission unit 115 is not approved. Can be canceled.

<3-2. Approval node (node 10B, 10C)>
Next, the functional configuration of the nodes 10B and 10C, which are the approval nodes, will be described with reference to FIG. 7. FIG. 7 is a functional block diagram of the node 10B according to the present embodiment. Since the functional configuration of the node 10C is the same as that of the node 10B, the description thereof is omitted. As shown in FIG. 7, the node 10B has a storage unit 131, a transaction acquisition unit 121, a transaction verification unit 122, a signature execution unit 123, and a transmission unit 124. In addition to the private key of user B, the above-mentioned distributed ledger 131 is recorded in the storage unit 131. However, not all approval nodes need to have the distributed ledger 131, and some approval nodes may have a configuration.

(1) Transaction acquisition unit 121
The transaction acquisition unit 121 acquires the transaction transmitted to the network N. For example, the transaction acquisition unit 121 can extract a transaction for which a signature request has been made to its own node from the received transaction.

(2) Transaction verification unit 122
The transaction verification unit 122 verifies the validity of the acquired transaction.
For example, the transaction verification unit 122 calculates the hash value from the acquired transaction excluding the area to be signed, and verifies the signature of the user A by collating with the decoded digest. This makes it possible to verify that the operator is user A and that the transaction has not been tampered with.

Further, the transaction verification unit 122 may verify the signature of the user A included in the transaction. Specifically, the transaction verification unit 122 refers to the database 30 and extracts the record corresponding to the acquired transaction ID. Next, the public key of user A is acquired from the extracted record, and the digest is decoded from the signature of user A. If the transaction includes the public key itself, or if the transaction is transmitted with the public key attached, the transaction verification unit 122 does not necessarily have to search the database 30 for the public key. ..

In the case of a key update transaction, the transaction verification unit 122 verifies each signature made by the private key before and after the update. However, if the key to be updated in the key update transaction is a key pair or common key that is different from the key for user A's signature, the key update transaction includes the signature with the user A's existing signature key. It will be. In this case, the transaction verification unit 122 verifies the signature of the user A generated by the signature key. Further, in the case of a key revocation transaction and the revocation operator is not the user A, the signature of the revocation operator is verified.

Further, the transaction verification unit 122 may verify whether or not other data included in the transaction is appropriate in addition to the above. For example, in the case of a key update transaction or a key expiration transaction, whether or not the hash value of the previous transaction included in the transaction is the correct value can be verified by calculating the hash value of the previous transaction. good. Further, for example, whether or not the key data included in the transaction is correct may be verified by collating with the data registered in the database 30. Specifically, when the transaction includes the hash value of the public key, the transaction verification unit 122 hashes from the hash value of the public key obtained by decrypting the signature and the public key registered in the database 30. Values can be calculated and matched.

(3) Signature execution unit 123
The signature execution unit 123 signs the transaction using the user B's signature key when the user B is designated as the approval request destination for the transaction whose validity has been verified by the transaction verification unit 122. I do. On the other hand, if the transaction is such that the user B is not requested to sign, no processing is performed.

(4) Transmitter 124
The transmission unit 124 transmits a transaction signed by the signature execution unit 123. At this time, if there is an unsigned user among the approvers who requested the signature from the user A of the node 10A, the transmission unit 124 may be configured to transfer the transaction to the unsigned user. The transaction may be returned to the user A regardless of the presence or absence of an unsigned user.

Further, the transmission unit 124 transmits the transaction to the entire network N when there is no unsigned user in the transaction acquired by the transaction acquisition unit 121, so that the distributed ledger 131 of the node 10 connected to the network N It is also possible to register a transaction in.

(5) Processing Flow With reference to FIG. 8, the processing flow when the node 10B approves the transaction will be described. FIG. 8 is a flowchart showing an example of the processing flow of the node 10B.

First, the transaction acquisition unit 121 acquires a transaction from the network N (S21). Next, the transaction verification unit 122 verifies the acquired transaction (S22).

If it is determined as a result of the verification that the transaction should be denied (S23: NO), the node 10B ends the process. At this time, the node 10B may be configured to notify the administrator of the access management system 1.

On the other hand, if it is determined as a result of verification that the transaction should be approved (S23: YES), and node B is specified as the approval request destination (S24: YES), the signature execution unit. 123 signs using the private key of user B (S25).

Finally, the transmission unit 124 transmits the transaction (S26). At this time, if the user set as the approval request destination includes an unapproved user, the transmission unit 124 transmits a transaction to the unapproved user or the user A. On the other hand, if there is no unapproved user, it is transmitted to each node 10 to the entire network N.

<4. Usage example>
An example of how to use the key managed in the access management system 1 will be described with reference to FIG. FIG. 9 is a schematic diagram for explaining the mechanism of access control using the key. In the example of FIG. 9, when the node 10A accesses the data or the like managed by the node 10B, the node 10B authenticates (identifies) the user A who uses the node 10A.

First, the node 10B transmits a randomly generated message (plaintext) to the node 10A. The message means any data for identity verification that is temporarily generated. The node 10A obtains a hash value (message digest) from the received message body (plaintext) by using a hash function (arrow (1)). Next, the message digest is encrypted with the private key of the user A stored in the storage unit 130 (arrow (2)). In the message, the node 10A uses information for identifying the public key corresponding to the private key used for signing (for example, a hash value or an identifier (ID) of the public key. In the following, the information for identifying the public key is referred to as "public key". (Also referred to as "ID") is attached (arrow (3)) and transmitted to node 10B (arrow (4)). Instead of the public key ID, a method of attaching the transaction ID in which the public key is registered, the public key itself, or the transaction data itself to the message is also conceivable.

On the other hand, the node 10B that received the message refers to the distributed ledger 131 and searches for a transaction that approves the operation on the public key corresponding to the public key ID based on the public key ID attached to the message. ,Extract. Further, node 10B verifies the extracted transaction. The verification process here is the same as the verification process of the transaction verification unit 122 described above.

At this time, the node 10B determines whether or not the distributed ledger 131 includes a transaction for further updating or revoking the key corresponding to the public key ID attached to the message after the extracted transaction. Is preferable. Specifically, in node 10B, is a transaction including a hash value of the extracted transaction (that is, a transaction that approves the operation on the key corresponding to the public key ID attached to the message) registered in the distributed ledger 131? Determine if not. When the transaction including the hash value of the extracted transaction is registered in the distributed ledger 131, the public key corresponding to the public key ID attached to the message has already expired. In this case, it is preferable that the node 10B determines that the signature of the user A is invalid and does not authenticate the user A.

Note that the node 10B repeatedly verifies whether or not the transaction including the hash value of the extracted transaction exists in the distributed ledger 131, so that the latest key information of the user A can be obtained. Can be confirmed.

Node 10B identifies the approver in the extracted transaction and obtains the public key of the identified approver by referring to the database 30. Using the acquired public key of the approver, the approver's signature included in the specified transaction is verified, and the legitimacy of the approver is confirmed (arrow (5)). That is, in this example, it can be said that the transaction in which the public key of the user A is approved proves the validity (reliability) of the public key of the user A instead of the digital certificate.

Further, the node 10B further includes a hash value (public key ID) of the public key of the user A included in the specified transaction, and a hash value obtained by using a hash function for the public key of the user A acquired from the database 30. It is also possible to compare and confirm whether the transaction ID is for approving the private key used this time.

Further, the node 10B decodes the user A's signature using the user A's public key (arrow (6)), and obtains a hash value (message digest) from the message body (plain text) using the same hash function as the node 10A. User A is authenticated by asking (arrow (7)) and checking by matching the two (arrow (8)). If the transaction includes the public key itself, the node 10B can acquire the public key of the user A from the specified transaction.

As described above, according to the access management system 1 according to the present embodiment, the user can prove the validity (reliability) of the user's key by the transaction in which the key to be used is approved by one or more users. That is, since it is possible to guarantee the reliability of the user's key to each other, even if the reliability of a certain user is impaired, the reliability of the entire system is continued based on the reliability of the approver. be able to. Further, by mutually approving the revocation of the key, the conventional centralized management by CRL (Certificate Revocation List) becomes unnecessary.

<Hardware configuration>
Hereinafter, with reference to FIG. 10, an example of a hardware configuration in which the node 10 and the database 30 described above in the first embodiment and the second embodiment are realized by the computer 800 will be described. The function of each device can be realized by dividing it into a plurality of devices.

As shown in FIG. 10, the computer 800 includes a processor 801 and a memory 803, a storage device 805, an input I / F unit 807, a data I / F unit 809, a communication I / F unit 811 and a display device 813.

The processor 801 controls various processes in the computer 800 by executing a program stored in the memory 803. For example, the key acquisition unit 111 of the nodes 10A and 10B, the key verification unit 112, the database control unit 116, the transaction generation unit 114, the signature execution unit 115, the transaction acquisition unit 121, the transaction verification unit 122, the signature execution unit 123, and the transmission unit. 124, etc. can be realized as a program that is temporarily stored in the memory 803 and mainly operates on the processor 801.

The memory 803 is a storage medium such as, for example, a RAM (Random Access Memory). The memory 803 temporarily stores the program code of the program executed by the processor 801 and the data required when the program is executed.

The storage device 805 is a non-volatile storage medium such as a hard disk drive (HDD) or a flash memory. The storage device 805 stores an operating system and various programs for realizing each of the above configurations. In addition, the storage device 805 can also store the distributed ledger 131. Such programs and data are referenced from the processor 801 by being loaded into the memory 803 as needed.

The input I / F unit 807 is a device for receiving input from the user. Specific examples of the input I / F unit 807 include a keyboard, a mouse, a touch panel, various sensors, a wearable device, and the like. The input I / F unit 807 may be connected to the computer 800 via an interface such as USB (Universal Serial Bus).

The data I / F unit 809 is a device for inputting data from the outside of the computer 800. Specific examples of the data I / F unit 809 include a drive device for reading data stored in various storage media. It is also conceivable that the data I / F unit 809 is provided outside the computer 800. In that case, the data I / F unit 809 is connected to the computer 800 via an interface such as USB.

The communication I / F unit 811 is a device for performing data communication via the Internet N by wire or wirelessly with an external device of the computer 800. It is also conceivable that the communication I / F unit 811 is provided outside the computer 800. In that case, the communication I / F unit 811 is connected to the computer 800 via an interface such as USB.

The display device 813 is a device for displaying various information. Specific examples of the display device 813 include a liquid crystal display, an organic EL (Electro-Luminescence) display, a display of a wearable device, and the like. The display device 813 may be provided outside the computer 800. In that case, the display device 813 is connected to the computer 800 via, for example, a display cable or the like.

[Other embodiments]
Each of the embodiments described above is for facilitating the understanding of the present invention, and is not for limiting the interpretation of the present invention. The present invention can be modified / improved without departing from the spirit thereof, and the present invention also includes an equivalent thereof. Further, each embodiment is an example, and it goes without saying that partial substitutions or combinations of the configurations shown in different embodiments are possible, and these are also included in the scope of the present invention as long as the features of the present invention are included. ..

For example, in the above-described embodiment, an example in which mining is not performed for a transaction has been described, but the present invention is not limited to this, and after mining is performed using PoW technology, the transaction is transferred to the distributed ledger 131. It may be configured to be registered.

Further, in the above-described embodiment, the configuration in which the key of the user A whose operation is approved in the transaction and the key of the user A who generates the signature in the transaction are paired has been described. However, the transaction is not limited to this, and the user A may be authorized to operate on a key pair different from the key for generating the signature (for example, the private key for signature). In this case, the transaction includes a signature with a private key paired with an existing public key that is different from the public key for which the operation is authorized by the transaction, and a private key encrypted with the existing public key. May be good. In generating such a transaction, the transaction generation unit 113 is encrypted with information (hash value or ID) for identifying the public key to be operated or an existing public key different from the public key to be operated. You can use the private key. Further, at this time, the signature execution unit 114 generates the signature of the user A in the transaction by using a private key paired with the existing public key, which is different from the public key whose operation is approved by the transaction. Further, in this case, the transaction verification unit 122 verifies the generated signature of the user A using the existing public key of the user A paired with the signed private key. ..

Further, in the above-described embodiment, the access control system 1 has described an example of managing a key pair based on a public key cryptosystem, but the present invention is not limited to this, and the access management system 1 manages a common key based on a common key cryptosystem. But it may be. In this case, the transaction includes the hash value of the common key, the common key itself encrypted with the existing public key, or the signature with the key for the signature of the user A. The signing key referred to here includes not only the private key of the public key cryptosystem but also the common key for authentication that generates and decrypts the message authentication code (MAC value). In the case of a common key, the signature points to the message authentication code (MAC value). In generating such a transaction, the transaction generation unit 113 can use information (hash value or ID) for identifying the common key to be operated. At this time, the sign execution unit 114 uses a common key whose operation is approved by the transaction, a common key for authentication different from the common key, or a private key paired with the existing public key for signing to be used by the user in the transaction. Generate A's signature or MAC value. Further, in this case, the transaction verification unit 122 displays the generated signature of the user A as a common key to be operated this time, a common key for authentication of the user A, and a public signature. Verify using the key.

1 Access control system 10A, 10B, 10C Node 30 Database 111 Key acquisition unit 112 Key verification unit 113 Transaction generation unit 113 Database control unit 114 Signature execution unit 115 Transmission unit 116 Database control unit 121 Transaction acquisition unit 122 Transaction verification unit 123 Signature execution Unit 124 Transmitter 130 Storage 131 Distributed Ledger

Claims (3)

A computer that has access to a distributed database in which transactions are managed,
An acquisition means for acquiring a first key for indicating the access authority of the first user and not associated with the first user in the distributed database.
Verification means for verifying the first key,
A sharing means for sharing information about the first key with one or more second user computers accessible to the distributed database.
The generation means for generating the first transaction including the information of the first key and the digital signature of the first user and requesting the approval of the use of the first key, and the first transaction are one or more of the above. A transmission means for transmitting the first transaction to the computer of the one or more second users in order to be digitally signed by the second user and registered in the distributed database.
It is a program that functions as
The acquisition means further
Instead of the first key, a second key indicating the access authority of the first user, which is not associated with the first user in the distributed database, is acquired.
The verification means further
After verifying the second key,
The sharing means further
Information about the second key is shared with the computers of the first or more second users.
The generation means further
Includes a digital signature generated using the first key, a digital signature generated using the second key, and a hash value of the first transaction, and requests approval for the use of the second key. Generate a second transaction,
The transmission means further
A program for transmitting the second transaction to the computer of the one or more second users so that the second transaction is digitally signed by the one or more second users and registered in the distributed database . The generation means further
Generates a third transaction that includes information indicating that the first key is revoked, the hash value of the first transaction, and the digital signature of the first user, and requests approval for the revocation of the first key. ,
The transmission means further
The third transaction is digitally signed to the one or more second users, to be registered in the distributed database, to claim 1 for transmitting the third transaction to the one or more second user's computer Described program. A decentralized database that manages transactions to authorize operations on keys that indicate user access rights, and
A first node and one or more second nodes that can access the distributed database,
Equipped with
The first node is
An acquisition unit that acquires the first key that is the first key for indicating the access authority of the first user and is not associated with the first user in the distributed database.
The first verification unit that verifies the first key and
A shared unit that shares information about the first key with the second node,
A generator that includes the information of the first key and the digital signature of the first user and generates a first transaction for requesting the second node to approve the use of the first key.
A first transmitter that transmits the first transaction to the second node,
Have,
The second node is
A second verification unit that verifies the validity of the first transaction based on the shared information about the first key and the digital signature of the first user.
A signature unit that generates a digital signature of the second user for the first transaction whose validity has been verified, and a signature unit.
A second transmitter that sends the first transaction to the distributed database,
Have a,
The acquisition unit further
Instead of the first key, a second key indicating the access authority of the first user, which is not associated with the first user in the distributed database, is acquired.
The first verification unit further
After verifying the second key,
The shared part further
Information about the second key is shared with the second node,
The generator further
Includes a digital signature generated using the first key, a digital signature generated using the second key, and a hash value of the first transaction, and requests approval for the use of the second key. Generate a second transaction,
The first transmission unit further
Sending the second transaction to the second node for the second transaction to be digitally signed by the second user and registered in the distributed database.
Access management system.

Images