WO2019163040A1 - アクセス管理システム、及びそのプログラム - Google Patents

アクセス管理システム、及びそのプログラム Download PDF

Info

Publication number
WO2019163040A1
WO2019163040A1 PCT/JP2018/006358 JP2018006358W WO2019163040A1 WO 2019163040 A1 WO2019163040 A1 WO 2019163040A1 JP 2018006358 W JP2018006358 W JP 2018006358W WO 2019163040 A1 WO2019163040 A1 WO 2019163040A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
transaction
user
node
signature
Prior art date
Application number
PCT/JP2018/006358
Other languages
English (en)
French (fr)
Inventor
淳 栗原
久保　健
Original Assignee
株式会社ゼタント
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社ゼタント filed Critical 株式会社ゼタント
Priority to JP2020501912A priority Critical patent/JP6976405B2/ja
Priority to PCT/JP2018/006358 priority patent/WO2019163040A1/ja
Publication of WO2019163040A1 publication Critical patent/WO2019163040A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the present invention relates to an access management system and its program.
  • an encryption-based control method has attracted attention as an access control method.
  • data is encrypted so that only the subject to which access is permitted can be decrypted, and the authority of the subject is verified based on whether the data can be decrypted (for example, Non-Patent Document 1). .
  • Non-Patent Document 1 a central server such as a certificate authority (CA) issues an access control encryption key or decryption key. 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, when the central server is hijacked, all keys issued based on the reliability of the central server become unreliable, so the central server is considered as a single point of failure (SPOF). turn into. To prevent this, increasing the security level of the central server is expensive.
  • SPOF single point of failure
  • the present invention aims to improve fault tolerance in encryption-based access control.
  • the program according to the present invention is a first key for indicating the access authority of a first user to a computer that can access a distributed database in which transactions are managed, and is not associated with the first user in the distributed database.
  • Acquisition means for acquiring a first key verification means for verifying the first key
  • sharing means for sharing information relating to the first key with one or more second user computers accessible to the distributed database first key
  • the program of the present invention can be installed or loaded on a computer 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.
  • recording media such as an optical disk such as a CD-ROM, a magnetic disk, and a semiconductor memory, or via a communication network.
  • unit does not simply mean a physical configuration, but also includes a case where the functions of the configuration are realized by software.
  • functions of one configuration may be realized by two or more physical configurations, or functions of two or more configurations may be realized by one physical configuration.
  • fault tolerance can be improved in encryption-based access control.
  • FIG. 1 shows an example of a system configuration of an access management 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 access authority of the user in encryption-based access control.
  • the keys used in the access management system 1 are a public key and a secret key in the public key cryptosystem.
  • the key encryption method used in the access management system 1 is not limited to the public key encryption method, and may be a common key encryption method, for example.
  • Key operations include key generation, renewal, or revocation.
  • a certain user performs an operation on the key
  • one or more other users approve it.
  • “approve the operation to the key” means to approve the key to be used when the operation to the key is generation / update, and to the revocation operation when the operation to the key is revoked. Is to approve.
  • approvers approve operations on the key
  • the users can mutually secure the reliability of the key. Thereby, 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.
  • the approver does not need 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, A different user may become an approver for each operation.
  • the scope of influence can be limited to keys that are approved only by the approver whose reliability is impaired. As a result, the reliability of the entire system can be continued.
  • an access management system 1 includes a plurality of nodes 10A, 10B, and 10C (hereinafter, these nodes are also simply referred to as “node 10”) connected to a network N such as the Internet. And a database 30.
  • node 10 nodes 10A, 10B, and 10C
  • network N such as the Internet
  • database 30 a database 30.
  • three nodes are described as an example, but the number of nodes is not limited.
  • the network N is configured by a wireless network or 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 GenerationMex), 4G (Registered Trademark), infrared communication, Bluetooth (Registered Trademark), wired LAN, telephone line, power line network, IEEE 1394, and other networks.
  • 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 later by downloading or the like.
  • the node 10 is a mobile phone, a smartphone, a PC (Personal Computer), a PDA (Personal Digital Assistant), a tablet, a wearable terminal, a server device, a game machine, or the like.
  • the nodes 10A and 10B and the node 10C are connected to each other via a network N through P2P (Peer to Peer), and constitute a distributed ledger system.
  • P2P Peer to Peer
  • the node 10 should just be comprised so that access to a distributed ledger system is possible, and is not necessarily limited to the aspect which comprises a distributed ledger system.
  • Each node may be directly P2P connected without going through the network N.
  • the users of the nodes 10A, 10B, and 10C are 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 in the access management system 1, a mail address, a node identifier, an ID identified by an application installed in the node, or the like.
  • node 10A As an operator, node 10A as an operation node, users B and C as approvers, and nodes 10B and 10C as approval nodes.
  • the operation node and the approval node do not have to be separate nodes, and a single node may have both functions of the operation node and the approval node.
  • the user of each node is not limited to one person, and one node may be shared by a plurality of users.
  • the database 30 is constructed in a storage management server connected to the network N in this embodiment.
  • the database 30 is not limited to this, and may be constructed on a WEB server connected to the network N, for example.
  • the node 10 may be connected to a private network, and the database 30 may be connected to a private network to which the node 10 is connected via the Internet.
  • the node 10 may be connected via the Internet, and the database 30 may be connected to a private network connectable to the Internet.
  • Database 30 In the database 30, key information managed in the access management system 1 is registered. As an example, a record in which a public key and an encrypted secret key are associated with each other is registered in the database 30. In this case, it is preferable that the transaction described later includes a public key and a hash value of the encrypted private key. As will be described later, the database 30 is not necessary when the transaction includes the main body of the public key.
  • Each record in the database 30 may include an identifier of a user who is the owner of the key, an ID of a transaction that has performed an operation on a 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 or not the user has made a fraud in the past in the access management system 1. Further, the database 30 may be configured to manage identifiers of public keys and private keys.
  • FIG. 2 is a functional block diagram of the node 10A according to the present embodiment.
  • the node 10A includes 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. Yes.
  • the storage unit 130 stores the secret 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 for all the nodes 10 to have the distributed ledger 131, and only a part of the nodes 10 may have the distributed ledger 131.
  • FIGS. 3 to 5 are diagrams schematically showing a part of the data structure of a transaction managed by the distributed ledger 131 (an example of a distributed database).
  • the distributed ledger 131 blocks each storing a plurality of transactions are recorded in a daisy chain structure that is connected in a row.
  • 3 to 5 show an example in which one block has only one transaction, but one block may have a plurality of transactions. Further, the transactions do not necessarily have to be stored in blocks, and a configuration in which the transactions themselves are connected in a daisy chain may be used.
  • FIG. 3 is a diagram illustrating an example of the structure of the block 1 including the key generation transaction (an example of the first transaction) managed in the distributed ledger 131.
  • the key generation transaction is a transaction for requesting approval of a generated new key.
  • FIG. 3 shows, as an example, a key generation transaction for approving a key (an example of a first key) generated by user A (an example of a first user).
  • -Key data generated by user A-Signature of user A-Signature of another user also referred to as an approver, one example of one or more second users
  • the generated key data is information that allows the user A to identify a key to be newly used, and is, for example, the hash value of the public key of the key pair approved in the key generation transaction.
  • a public key data itself or a unique identifier in the public key access management system 1 may be stored in the key generation transaction instead of the public key hash value.
  • the key generation transaction may further include a public key to be generated or a secret key encrypted with another existing public key.
  • the generated public / private key pair is not limited to the individual user A key pair, and may be a key pair used in a service provided by the user A.
  • User A's signature is a digital signature generated using the private key of the key pair approved in the key generation transaction.
  • digital signature is also simply referred to as “signature”
  • generating a digital signature using a key is also simply referred to as “signing” or “signing”.
  • the approver's signature is a signature generated by an arbitrary number of users other than user A using his / her private key when approving the generated key.
  • the key generation transaction includes the signatures of two users (users B and C), but the number of approver signatures may be any number greater than or equal to one.
  • the user who generates a signature as an approver can be specified by, for example, user A (that is, a user who newly generates a key).
  • 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.
  • the number of necessary approver signatures may be determined in advance by the administrator of the access management system 1, may be specified by the user A, or may be determined randomly. That is, the user selected as the approver in the key generation transaction is not fixed but indefinite.
  • the signature of each user is the data excluding the area where the signature is generated in the key generation transaction (that is, “the key data generated by user A (the public key in this embodiment).
  • the hash value) ”) is used as a digest, and is generated by encrypting the digest using its own secret key.
  • FIG. 4 is a diagram showing an example of the structure of the block B2 including the key update transaction (an example of the second transaction) managed in the distributed ledger 131.
  • the key update transaction is a transaction for requesting approval for updating a key (an example of a first key) approved in the access management system 1 to a new key (an example of a second key). It is.
  • FIG. 4 shows, as an example, a key update transaction when the nth update is performed on the key of user A approved in the key generation transaction shown in FIG.
  • the key update transaction is stored in the key update transaction.
  • -Hash value of previous transaction data -Data of updated key of user A-Signature of user A-Signature of other user (authorizer)
  • the key update transaction is the previous one It may contain a pointer to the transaction.
  • the previous transaction indicates a transaction for updating the key for the (n-1) th time. If the current key update transaction is a key update for the first time, the previous transaction indicates a key generation transaction. Of course, the transaction immediately before the key update transaction also includes the hash value of the previous transaction data. As described above, all the key update transactions have a data structure that is linked to the key generation transaction. Then, the key update transaction includes a hash value of the update history of all keys from the transaction in which the key is generated to the key update transaction. By adopting such a configuration for the key update transaction, even if the intermediate transaction is falsified, the detection becomes easy.
  • the updated key data is, for example, a hash value of the updated public key that is approved as a new key in a key update transaction.
  • the updated key data may be information that can identify a new key, and may be, for example, a public key identifier.
  • the key update transaction may further include an updated secret key encrypted with the updated public key.
  • User A's signature is a signature generated using each private key before and after the update.
  • the signature is generated by using the updated private key at this time (nth) and the updated private key at the previous time (n ⁇ 1).
  • the key updated in the key update transaction is a key different from the key used for the signature of the user A, such as a key used in the service provided by the user A, the user A uses the signature It is also possible to generate a signature using a key.
  • the approver's signature is a signature generated by an arbitrary number of users other than the user A using his / her private key when approving the updated key.
  • the approver's signature is, for example, the same user signature as the approver's signature included in the key generation transaction that is the origin of the key update transaction.
  • the present invention is not limited to this, and the configuration of the user who signs as an approver and the number thereof may be selected by the user A (key updater) for each key update transaction, or may be determined at random.
  • a configuration in which an administrator of the access management system 1 sets a user to sign in accordance with the number of updates may be used. That is, the user selected as the approver in the key update transaction is not fixed but indefinite.
  • the signature of each user is the data of the key update transaction excluding the area where the signature is performed (that is, “the hash value of the previous transaction data” and “the updated key of user A”).
  • the hash value of the data (in this embodiment, the hash value of the public key) ”) is used as a digest, and the digest is generated using its own private key.
  • FIG. 5 is a diagram showing an example of the structure of the block B3 including the key revocation transaction (an example of the third transaction) managed in the distributed ledger 131.
  • the key revocation transaction is a transaction for revoking the key generated in the access management system 1.
  • FIG. 5 shows, as an example, a key revocation transaction for revoking the user A key generated in the key generation transaction shown in FIG.
  • the key revocation transaction is stored in the key revocation transaction.
  • the key revocation transaction is transferred to the previous transaction. May be included.
  • User A's key revocation information is information that can specify that user A's key has been revoked.
  • the revocation information includes, for example, a key revocation date, a revocation reason, and the like.
  • the reasons for revocation typically include application from the key owner (lost or stolen secret key, suspension of service use, etc.), as well as revocation registration by the system administrator (violation of user obligations, etc.).
  • the revocation information may further include information (for example, a public key body and an encrypted private key) that can identify a key to be revoked.
  • User A's signature is, for example, a signature generated using a key to be revoked.
  • 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 a key used in the service provided by the user A
  • the user A uses the signature It is also possible to generate a signature using a key. If the user who performs the revocation operation is a user other than the user A (that is, a user other than the owner of the key to be revoked), the signature of the user A (key owner) may not be present. In this case, the key revocation transaction includes the revocation operator's signature instead of the user A's signature.
  • the signature of the approver is a signature generated by an arbitrary number of users other than the user A using his / her private key when approving the key revocation.
  • the user who signs as the approver and the number thereof may be the same user signature as the approver's signature included in the key generation transaction that is the origin, or the revoker or the administrator of the access management system 1 as in the key update transaction. May be specified, or may be determined at random. That is, the user selected as the approver in the key revocation transaction is not fixed but indefinite.
  • each user's signature is data excluding the area in which the signature is generated in the key update transaction (that is, “the hash value of the previous transaction data” and “user A's key revocation). It is generated by using the hash value of “information”) as a digest and encrypting the digest using its own private key.
  • the key generation transaction the key update transaction, and the key revocation transaction are collectively referred to as a single “transaction”.
  • the key acquisition unit 111 (which is an example of an acquisition unit) acquires information about a key to be operated. For example, when the operation is key generation, the key acquisition unit 111 can generate a key.
  • the generated key is a key that is not associated with the user A in the distributed ledger 131 and / or the database 30.
  • 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.
  • the key acquisition unit 111 refers to the database 30 and acquires the update target key.
  • the key acquisition unit 111 does not perform processing. However, also in this case, the key acquisition unit 111 may acquire the revocation target key with reference to the database 30.
  • the key acquisition unit 111 can search the database 30 based on the transaction ID and the identifier of the user A for which the operation target key is approved.
  • the key acquisition unit 111 may be configured to request generation of a key from another node and acquire the key generated at the other node instead of generating the key.
  • the other node that generates the key is preferably a management node of the access management system 1, for example.
  • the key verification unit 112 (an example of a verification unit) verifies whether at least a 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 the data encrypted by one key can be decrypted by the other key with respect to the key pair generated by the key acquisition unit 111 or the key pair requested to be generated by another node. Do.
  • Transaction generation unit 113 (which is an example of a generation unit) generates a transaction related to the key operation. The generation process of each component of the transaction will be specifically described.
  • the transaction generation unit 113 generates a hash value as key data, for example, from a public key verified by the key verification unit 112 using a predetermined hash function.
  • the transaction generation unit 113 may use a public key identifier as key data. If the transaction includes an encrypted secret key, the transaction generation unit 113 encrypts the secret key using a public key corresponding to the secret key or another existing public key.
  • the transaction generation unit 113 when the transaction to be generated is a key update transaction or a key revocation transaction, the transaction generation unit 113 generates a hash value of the previous transaction.
  • the transaction immediately before the transaction generated this time is a transaction in which the key to be operated (updated / revoked) is approved. Therefore, first, the transaction generation unit 113 identifies the transaction ID for which the key to be operated is approved.
  • the transaction generation unit 113 may have a configuration in which the transaction ID is designated by the user A, or accepts the designation of the key to be updated from the user A, refers to the database 30 and corresponds to the transaction corresponding to the designated key.
  • the structure which specifies ID may be sufficient.
  • the transaction generation unit 113 refers to the distributed ledger 131, acquires a transaction corresponding to the specified transaction ID, and calculates a hash value of the transaction.
  • the transaction generation unit 113 further generates revocation information.
  • the revocation information can be generated by receiving an input from the user A, for example.
  • the transaction generation unit 113 assigns a unique transaction ID in the network N and generates a transaction.
  • Signature execution unit 114 The signature execution unit 114 signs the transaction using the signature key for the user A. As an example, the signature execution unit 114 calculates a hash value of data excluding an area in which the signature is stored in the transaction generated by the transaction generation unit 113, and generates a digest. Then, the signature execution unit 114 performs signature by encrypting the generated digest using the private key of the user A.
  • the secret key used for signature here is, for example, a generated secret key in the case of a key generation transaction, a secret key before and after update in the case of a key update transaction, and a secret key to be revoked in the case of a key revocation transaction. It is.
  • a key operated in a transaction and a key for generating a signature are not necessarily paired.
  • the signature execution unit 114 uses the existing signature key for the user A (that is, in the transaction).
  • a signature is generated by encrypting the generated digest using a key different from the key to be operated.
  • the transmission unit 115 (an example of a transmission unit) transmits the transaction signed by the signature execution unit 115 to the approval request destination node. At this time, the transmission unit 115 sets the identifier of the other user (approver) who requests the transaction for approval (that is, requests a signature) as an approval request destination.
  • the transmission unit 115 may be configured to accept designation of an approver as an approval request destination from the user A of the node 10A, or may be configured to set a predetermined approver from the administrator of the access management system 1. The configuration may be such that the user of the access management system 1 randomly selects and sets.
  • the transmission unit 115 transmits the transaction to the approval request destination, the public key that can decrypt the signature performed by the signature execution unit 115 (that is, a newly generated public key, an updated public key, an expired public key) The target public key) may be transmitted together.
  • the transmission unit 115 can also transmit the transaction to the entire network N.
  • Database control unit 116 The database control unit 116 (an example of a sharing unit) 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 “generation”, the database control unit 116 adds a new record to the database 30, and the public key and the private key encrypted with the public key. Register.
  • the database control unit 116 refers to the database 30 and extracts a record corresponding to the key to be updated, and the updated public key and the updated public key are included in the extracted record. Add a private key encrypted with the public key.
  • the database control unit 116 may be configured to replace the public key before update and the encrypted secret key with the updated public key and encrypted secret key.
  • the database control unit 116 refers to the database 30 and deletes the record corresponding to the revocation target key.
  • the database control unit 116 may be configured to add revocation information to the extracted record instead of deleting the record.
  • the database control unit 116 registers the transaction identifier (hereinafter also referred to as “transaction ID”) generated by the transaction generation unit 114 in association with the key in the database 30. It is preferable to keep it.
  • the database control unit 116 may share the key with other nodes by a method of registering in the database 30 or transmitting the key directly to another node.
  • the database control unit 116 registers the verified key in the database 30 before the transmission unit 115 transmits the transaction. In this case, when the transmitted transaction is not approved by the approver, the database control unit 116 rolls back the registered content.
  • 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 when the signature of the transaction by the approver is completed.
  • the structure to perform may be sufficient.
  • the transaction includes the public key itself that can decrypt the signature of the user A, or the database control unit 116 transmits the public key together when the transmission unit 115 transmits the transaction.
  • FIG. 6 is a flowchart showing an example of the processing flow of the node 10A.
  • the key acquisition unit 111 acquires a key to be operated (S11).
  • the key acquisition unit 111 acquires a key to be operated by generating a key or searching the database 30 according to the operation content.
  • 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 10 ⁇ / b> A may be configured to notify the administrator of the access management system 1.
  • the transaction generation unit 113 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 an 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). Note that the context of the process of S17 and the processes of S14 to S16 is arbitrary.
  • 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.
  • 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 is omitted.
  • the node 10B includes a storage unit 131, a transaction acquisition unit 121, a transaction verification unit 122, a signature execution unit 123, and a transmission unit 124.
  • the above-described distributed ledger 131 is recorded in the storage unit 131.
  • the transaction acquisition unit 121 acquires a transaction transmitted to the network N.
  • the transaction acquisition unit 121 can extract a transaction for which a signature request is made for the own node from the received transaction.
  • the transaction verification unit 122 verifies the validity of the acquired transaction. For example, the transaction verification unit 122 calculates a hash value from data obtained by excluding a region where a signature is to be obtained from the acquired transaction, and verifies the signature of the user A by matching with the decrypted digest. As a result, it is possible to verify that the operator is the user A and that the transaction has not been tampered with.
  • 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 a record corresponding to the acquired transaction ID. Next, the public key of the user A is acquired from the extracted record, and the digest is decrypted from the signature of the user A. When the transaction includes the public key itself or when the transaction is transmitted with the public key attached, the transaction verification unit 122 does not necessarily need to search the database 30 for the public key. .
  • the transaction verification unit 122 verifies each signature performed with the secret key before and after the update.
  • the key to be updated in the key update transaction is a key pair or a common key different from the signature key for user A
  • the key update transaction includes a signature with the existing signature key for user A. It will be.
  • the transaction verification unit 122 verifies the signature of the user A generated with the signature key.
  • the signature of the revocation operator is verified.
  • the transaction verification unit 122 may verify whether 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 revocation transaction, whether or not the hash value of the previous transaction included in the transaction is a 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 data registered in the database 30. Specifically, when the transaction includes a hash value of the public key, the transaction verification unit 122 uses the hash value of the public key obtained by decrypting the signature and the hash of the public key registered in the database 30. The value can be calculated and matched.
  • Signature execution unit 123 If the transaction verified by the transaction verification unit 122 is a transaction for which the user B is designated as an approval request destination, the signature execution unit 123 signs the transaction using the signature key for the user B. I do. On the other hand, if the transaction is a transaction for which user B is not requested to be signed, no processing is performed.
  • the transmission unit 124 transmits the transaction signed by the signature execution unit 123. At this time, when 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 configuration may be such that the transaction is returned to the user A regardless of whether or not there is an unsigned user.
  • the transmission unit 124 transmits a 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 is sent. It is also possible to register a transaction.
  • FIG. 8 is a flowchart showing an example of the processing flow of the node 10B.
  • the transaction acquisition unit 121 acquires a transaction from the network N (S21).
  • the transaction verification unit 122 verifies the acquired transaction (S22).
  • the node 10B ends the process. At this time, the node 10B may be configured to report to the administrator of the access management system 1.
  • the signature execution unit 123 performs a signature using the secret key of user B (S25).
  • the transmission unit 124 transmits a transaction (S26). At this time, if there is an unapproved user among the users set as the approval request destination, the transmission unit 124 transmits the 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 over the entire network N.
  • FIG. 9 is a schematic diagram for explaining a mechanism of access control using the key.
  • the node 10A accesses data or the like managed by the node 10B
  • the node 10B authenticates (identifies) the user A who uses the node 10A.
  • the node 10B transmits a randomly generated message (plain text) to the node 10A.
  • the message means any data that is temporarily generated and is used for identity verification.
  • the node 10A obtains a hash value (message digest) by using a hash function for the received message body (plain text) (arrow (1)).
  • the message digest is encrypted with the private key of user A stored in the storage unit 130 (arrow (2)).
  • the node 10A is information (for example, a hash value or identifier (ID) of the public key) that identifies the public key corresponding to the secret key used for the signature in the message. ID (also referred to as “ID”) is attached (arrow (3)) and transmitted to the node 10B (arrow (4)).
  • ID also referred to as “ID”
  • the node 10B that has received the message refers to the distributed ledger 131 and searches for a transaction that has approved an operation on the public key corresponding to the public key ID based on the public key ID attached to the message. ,Extract. Further, the 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.
  • the node 10B determines whether 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. It is preferable. Specifically, the node 10B determines whether the transaction including the hash value of the extracted transaction (that is, the transaction that approved the operation to the key corresponding to the public key ID attached to the message) is registered in the distributed ledger 131. Determine whether or not. When a 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.
  • the node 10B repeatedly verifies whether or not a transaction including the hash value of the extracted transaction exists in the distributed ledger 131 for the transaction including the hash value of the extracted transaction. Can be confirmed.
  • the node 10B specifies the approver in the extracted transaction, and acquires the public key of the specified approver with reference to the database 30. Using the acquired approver's public key, the approver's signature included in the identified transaction is verified to confirm the validity of the approver (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.
  • the node 10B further includes a hash value (public key ID) of the public key of the user A included in the identified transaction, and a hash value obtained by using a hash function for the public key of the user A acquired from the database 30. And confirming whether the transaction ID is for approving the secret key used this time.
  • a hash value public key ID
  • a hash value obtained by using a hash function for the public key of the user A acquired from the database 30.
  • the node 10B decrypts the signature of the user A using the public key of the user A (arrow (6)), and also uses the same hash function as the node 10A from the message body (plain text) to obtain a hash value (message digest).
  • User A is authenticated by requesting (arrow (7)) and checking both (arrow (8)). If the transaction includes the public key itself, the node 10B can acquire the public key of the user A from the identified transaction.
  • the user can prove the validity (reliability) of the user's key by a 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 reciprocally approving the key revocation, the centralized management by the conventional CRL (Certificate Revocation List) becomes unnecessary.
  • the computer 800 includes a processor 801, 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.
  • the key acquisition unit 111, 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 of the nodes 10A and 10B. 124, etc. can be realized as programs that operate mainly on the processor 801 after being temporarily stored in the memory 803.
  • the memory 803 is a storage medium such as a RAM (Random Access Memory).
  • the memory 803 temporarily stores a program code of a program executed by the processor 801 and data necessary for executing the program.
  • the storage device 805 is a non-volatile storage medium such as a hard disk drive (HDD) or flash memory.
  • the storage device 805 stores an operating system and various programs for realizing the above-described configurations.
  • the storage device 805 can store the distributed ledger 131.
  • Such programs and data are referred to by the processor 801 by being loaded into the memory 803 as necessary.
  • 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, and a wearable device. The input I / F unit 807 may be connected to the computer 800 via an interface such as USB (Universal Serial Bus).
  • 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.
  • the data I / F unit 809 may be provided outside the computer 800. In this case, the data I / F unit 809 is connected to the computer 800 via an interface such as a USB.
  • the communication I / F unit 811 is a device for performing data communication with an external device of the computer 800 via the Internet N by wire or wireless.
  • the communication I / F unit 811 may be 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 a 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, and a wearable device display.
  • 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.
  • the present invention is not limited to this, and the transaction is stored in the distributed ledger 131 after performing mining using the PoW technology. It may be configured to register.
  • the present invention is not limited to this, and in a transaction, an operation for a key pair that is different from a key for generating a signature by user A (for example, a secret key for signature) may be approved.
  • the transaction includes a signature with a secret key paired with the existing public key, which is different from the public key whose operation is approved by the transaction, and a secret key encrypted with the existing public key. Also good.
  • the transaction generation unit 113 is encrypted with information (hash value or ID) for identifying a public key to be operated or an existing public key different from the public key to be operated. Private key can be used.
  • the signature execution unit 114 generates a signature of the user A in the transaction using a secret key that is different from the public key whose operation is approved by the transaction and is paired with the existing public key.
  • the transaction verification unit 122 verifies the generated signature of the user A using the existing public key of the user A that is paired with the private key that has signed the transaction. .
  • the transaction includes a hash value of the common key, a common key itself encrypted with an existing public key, or a signature by the user A's signature key.
  • the signature key here includes not only a secret key of a public key cryptosystem but also a common key for authentication for generating and decrypting a message authentication code (MAC value).
  • MAC value message authentication code
  • the signature indicates a message authentication code (MAC value).
  • the transaction generation unit 113 can use information (hash value or ID) for identifying a common key to be operated.
  • ID information for identifying a common key to be operated.
  • the signature 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 secret key that is paired with an existing public key for signature. Generate A's signature or MAC value. Further, in this case, the transaction verification unit 122, the transaction verification unit 122, the generated signature of the user A, the common key to be operated this time, the common key for authentication of the user A, the disclosure of the signature Verify using the key.

Abstract

暗号化ベースのアクセス制御において、耐障害性を向上させることができる。　トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、第１ユーザのアクセス権限を示すための第１鍵であって、分散型データベースにおいて第１ユーザに関連づけられていない第１鍵を取得する取得手段、第１鍵の検証を行う検証手段、第１鍵に関する情報を、分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、第１鍵の情報と、第１ユーザのデジタル署名とを含み、第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び第１トランザクションが、１以上の第２ユーザにデジタル署名され、分散型データベースに登録されるために、第１トランザクションを１以上の第２ユーザのコンピュータに送信する送信手段、として機能させる。

Description

アクセス管理システム、及びそのプログラム
　本発明は、アクセス管理システム、及びそのプログラム等に関する。
　近年、アクセス制御の方法として、暗号化ベースの制御方法が注目されている。暗号化ベースのアクセス制御方法では、アクセスが許可される主体のみが復号可能にデータが暗号化され、当該データの復号可否に基づいて、主体の権限の検証が行われる（例えば非特許文献１）。
S. Kamara and K. Lauter, "Cryptographic cloud storage," in Proc. FC 2010, Jan. 2010, pp. 136-149
　非特許文献１をはじめとする従来の暗号化ベースのアクセス制御方法では、認証局（ＣＡ：Certificate Authority）等の中央サーバが、アクセス制御用の暗号鍵や復号鍵を発行する。したがって、従来の暗号化ベースのアクセス制御方法によって管理されるシステムでは、システムの信頼性は、中央サーバの信頼度に依存することになる。このようなシステムでは、中央サーバが乗っ取られると、中央サーバの信頼性に基づいて発行されたすべての鍵が信頼できなくなることから、中央サーバが単一障害点（ＳＰＯＦ：Single Point Of Failure）となってしまう。これを防ぐために中央サーバのセキュリティレベルを強化するには大きな費用がかかってしまう。
　そこで、本発明は、上記事情に鑑み、暗号化ベースのアクセス制御において、耐障害性を向上させることを目的とするものである。
　本発明によるプログラムは、トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、第１ユーザのアクセス権限を示すための第１鍵であって、分散型データベースにおいて第１ユーザに関連づけられていない第１鍵を取得する取得手段、第１鍵の検証を行う検証手段、第１鍵に関する情報を、分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、第１鍵の情報と、第１ユーザのデジタル署名とを含み、第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び第１トランザクションが、１以上の第２ユーザにデジタル署名され、分散型データベースに登録されるために、第１トランザクションを１以上の第２ユーザのコンピュータに送信する送信手段、として機能させる。
　本発明のプログラムは、ＣＤ－ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
　また、本明細書等において、「部」とは、単に物理的構成を意味するものではなく、その構成が有する機能をソフトウェアによって実現する場合も含む。また、１つの構成が有する機能が２つ以上の物理的構成により実現されても、２つ以上の構成の機能が１つの物理的構成により実現されてもよい。
　本発明によれば、暗号化ベースのアクセス制御において、耐障害性を向上させることができる。
本発明の実施形態におけるアクセス管理システムの構成図である。 本発明の実施形態におけるノードの機能ブロックの一例を示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるノードの処理の流れの一例を示すフローチャートである。 本発明の実施形態におけるノードの機能ブロックの一例を示す図である。 本発明の実施形態におけるノードの処理の流れの一例を示すフローチャートである。 本発明の実施形態におけるユーザ認証の仕組みを模式的に示す図である。 本発明の実施形態における端末のハードウェア構成の一例を示す図である。
　［第１の実施形態］
　以下、本発明の実施の形態の１つについて詳細に説明する。なお、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。
＜１．システム構成の概要＞
　図１は、本発明に係るアクセス管理システム１のシステム構成の一例を示している。アクセス管理システム１は、暗号化ベースのアクセス制御に用いられる鍵への操作の管理を行う。鍵は、暗号化ベースのアクセス制御において、ユーザのアクセス権限を示す情報として用いられる。本実施形態では、アクセス管理システム１で用いられる鍵は、公開鍵暗号方式における公開鍵及び秘密鍵である。ただし、アクセス管理システム１において用いられる鍵の暗号方式は、公開鍵暗号方式に限定されず、例えば共通鍵暗号方式でもよい。
　鍵への操作は、鍵の生成、更新、又は失効を含む。アクセス管理システム１では、あるユーザ（操作者）が鍵に対して操作を行う場合、他の１以上のユーザ（承認者）が承認を行う。ここで、「鍵への操作を承認する」とは、鍵への操作が生成・更新である場合、使用される鍵を承認することであり、鍵への操作が失効である場合、失効操作を承認することである。１以上の承認者が、鍵への操作を承認することで、鍵の信頼性をユーザが相互に担保することが可能となる。これにより、アクセス管理システム１においては、一部の承認者の信頼性が損なわれたとしても、他の承認者の信頼性に基づいて、システム全体の信頼性を継続することができる。
　さらにアクセス管理システム１では、承認者は、固定のユーザである必要はなく、操作対象の鍵の所有者に応じて異なってもよく、また、鍵の所有者が同一であっても、鍵への操作のたびに異なるユーザが承認者になってもよい。この結果、ある承認者の信頼性が損なわれたとしても、影響範囲を、信頼性が損なわれた承認者にのみ承認された鍵に限定することができる。これによって、システム全体としては、信頼性を継続することができる。
　図１に示すように、アクセス管理システム１は、インターネット等のネットワークＮに接続された複数のノード１０Ａ、１０Ｂ、１０Ｃ（以下、これらのノードをまとめて単に「ノード１０」とも呼ぶ。）と、データベース３０とを備えている。図１の例では、一例として３つのノードを記載しているが、ノードの数に限定はない。
　ネットワークＮは、無線ネットワークや有線ネットワークにより構成される。通信ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ－ｐｈｏｎｅ Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークがある。
　ノード１０は、ネットワークＮに接続されたコンピュータであり、アクセス管理システム１が提供する所定のアプリケーションがインストールされている。なお、所定のアプリケーションは、ノード１０にあらかじめインストールされていてもよいし、ダウンロード等によってノード１０に事後的にインストールされてもよい。
　典型的には、ノード１０は、携帯電話やスマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔｓ）、タブレット、ウェアラブル（Ｗｅａｒａｂｌｅ）端末、サーバ装置、ゲーム機等である。ノード１０Ａ、１０Ｂ、及びノード１０Ｃは、ネットワークＮを介して互いにＰ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）接続されており、分散型台帳システムを構成している。もっとも、ノード１０は分散型台帳システムにアクセス可能に構成されていればよく、必ずしも分散型台帳システムを構成する態様に限定されない。なお、各ノードはネットワークＮを介さずに直接Ｐ２Ｐ接続されてもよい。
　以下の説明では、ノード１０Ａ，１０Ｂ，１０Ｃのユーザを、それぞれユーザＡ，Ｂ，Ｃとする。ユーザＡ，Ｂ，Ｃのそれぞれにはアクセス管理システム１で一意な識別子が割り当てられている。識別子は、例えば、ユーザがアクセス管理システム１に登録を行う場合に付与される一意な識別子や、メールアドレス、ノードの識別子、ノードにインストールされるアプリケーションにより識別されるＩＤ等である。
　一例として、ユーザＡを操作者、ノード１０Ａを操作ノードとし、ユーザＢ，Ｃを承認者、ノード１０Ｂ，１０Ｃを承認ノードとして説明する。なお、操作ノードと承認ノードとは別ノードである必要はなく、単一のノードが操作ノードと承認ノードとの双方の機能を有する構成でもよい。また、各ノードのユーザは一人に限定されず、１つのノードが複数のユーザによって共有されてもよい。
　データベース３０は、本実施形態ではネットワークＮに接続される、ストレージ管理用のサーバに構築される。なお、これに限定されず、データベース３０は、例えばネットワークＮに接続されるＷＥＢサーバ上に構築されてもよい。
　なお、本実施形態では、アクセス管理システム１の各構成は、ネットワークＮを介して接続される例を説明するが、これに限定されない。例えば、ノード１０はプライベートなネットワークに接続され、データベース３０はノード１０が接続されるプライベートなネットワークとインターネットを介して接続される構成でもよい。同様に、ノード１０はインターネットを介して接続され、データベース３０はインターネットに接続可能なプライベートなネットワークに接続される構成でもよい。
＜２．データベース３０＞
　データベース３０には、アクセス管理システム１において管理される鍵の情報が登録されている。一例として、データベース３０には、公開鍵と、暗号化された秘密鍵と、が対応付けられたレコードが登録されている。この場合には、後述するトランザクションには公開鍵と、暗号化された秘密鍵のハッシュ値が含まれることが好ましい。なお、後述するように、トランザクションに公開鍵の本体が含まれる場合には、データベース３０はなくてもよい。また、データベース３０の各レコードは、鍵の所有者であるユーザの識別子や、登録されている鍵に操作を行ったトランザクションのＩＤ、ユーザの信頼度を示す情報等を含んでもよい。ユーザの信頼度を示す情報は、例えば、アクセス管理システム１においてそのユーザが過去に不正を行ったか等を示す情報である。さらに、データベース３０には、公開鍵や秘密鍵の識別子が管理される構成でもよい。
＜３．ノード１０＞
＜３－１．操作ノード（ノード１０Ａ）＞
　次に、図２を用いて操作ノードであるノード１０Ａの機能構成について説明する。図２は、本実施形態に係るノード１０Ａの機能ブロック図である。図２に示すように、ノード１０Ａは、記憶部１３０と、鍵取得部１１１と、鍵検証部１１２と、トランザクション生成部１１４と、署名実行部１１５と、データベース制御部１１６と、を有している。さらに、図２に示すように、記憶部１３０には、ユーザＡの秘密鍵と、分散型台帳１３１が記録されている。分散型台帳１３１は、分散型台帳システムを構成する複数のノード１０に格納される分散型データベースである。ただし、すべてのノード１０が分散型台帳１３１を有している必要はなく、一部のノード１０のみが分散型台帳１３１を有している構成でもよい。
（１）分散型台帳
　図３乃至図５は、分散型台帳１３１(分散型データベースの一例である。）で管理するトランザクションのデータ構造の一部を模式的に示す図である。分散型台帳１３１では、複数のトランザクションそれぞれを格納したブロックが、１列に連なった数珠つなぎの構造で記録されている。なお、図３乃至図５の例では、１つのブロックは１つのトランザクションしか有していない例を示しているが、１つのブロックが複数のトランザクションを有してもよい。また、トランザクションは必ずしもブロックに格納されている必要はなく、トランザクションそのものが数珠つなぎとなっている構成でもよい。
　図３は、分散型台帳１３１において管理される鍵生成トランザクション（第１トランザクションの一例である。）を含むブロック１の構造の一例を示す図である。鍵生成トランザクションは、生成した新たな鍵の承認を求めるトランザクションである。図３では一例として、ユーザＡ（第１ユーザの一例である。）が生成した鍵（第１鍵の一例である。）の承認のための鍵生成トランザクションを示している。
　鍵生成トランザクションには、例えば、以下のデータが格納されている。
・ユーザＡの生成された鍵のデータ
・ユーザＡの署名
・他ユーザ（承認者ともいう。１以上の第２ユーザの一例である。）の署名
　生成された鍵のデータは、ユーザＡが新たに使用する鍵を識別可能な情報であり、例えば鍵生成トランザクションにおいて承認される鍵ペアの公開鍵のハッシュ値である。なお、生成された鍵のデータとして、公開鍵のハッシュ値の代わりに公開鍵のデータそのものや、公開鍵のアクセス管理システム１において一意な識別子が鍵生成トランザクションに格納される構成でもよい。また、鍵生成トランザクションは、さらに生成される公開鍵あるいは既存の別の公開鍵で暗号化された秘密鍵を含んでもよい。また、生成される公開鍵と秘密鍵の鍵ペアは、ユーザＡ個人の鍵ペアに限定されず、ユーザＡが提供するサービスで利用される鍵ペアでもよい。
　ユーザＡの署名は、鍵生成トランザクションにおいて承認される鍵ペアの秘密鍵を用いて生成されたデジタル署名である。なお、以下の説明では「デジタル署名」を単に「署名」ともいい、「鍵を用いてデジタル署名を生成」することを、単に「署名する」や「署名を行う」ともいう。
　承認者の署名は、ユーザＡ以外の任意の数のユーザが、生成された鍵を承認する際に、自身の秘密鍵を用いて生成した署名である。図３の例では、鍵生成トランザクションには２人のユーザ（ユーザＢ，Ｃ）の署名が含まれているが、承認者の署名の数は、１以上の任意の数でよい。また、承認者として署名を生成するユーザは、例えば、ユーザＡ（つまり、新たに鍵を生成するユーザ）が指定することができる。他にも、承認者は、アクセス管理システム１に含まれるノード１０のユーザからランダムに選択されてもよいし、あらかじめアクセス管理システム１の管理者によって選択されたユーザでもよい。また、必要な承認者の署名の数は、あらかじめアクセス管理システム１の管理者により定められてもよいし、ユーザＡにより指定されてもよいし、ランダムに決定されてもよい。つまり、鍵生成トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。
　なお、本実施形態では、各ユーザの署名は、鍵生成トランザクションのうち、署名が生成される領域を除いたデータ（すなわち、「ユーザＡの生成された鍵のデータ（本実施形態では公開鍵のハッシュ値）」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。
　図４は分散型台帳１３１において管理される鍵更新トランザクション（第２トランザクションの一例である。）を含むブロックＢ２の構造の一例を示す図である。鍵更新トランザクションは、アクセス管理システム１において承認された鍵（第１鍵の一例である。）を新たな鍵（第２鍵の一例である。）に更新することについて、承認を求めるためのトランザクションである。図４では一例として、図３に示した鍵生成トランザクションにおいて承認されたユーザＡの鍵についてｎ回目の更新を行う際の鍵更新トランザクションを示している。
　鍵更新トランザクションには、例えば、以下のデータが格納されている。
・１つ前のトランザクションデータのハッシュ値
・ユーザＡの更新済みの鍵のデータ
・ユーザＡの署名
・他ユーザ（承認者）の署名
　なお、鍵更新トランザクションは、上記の他に、１つ前のトランザクションへのポインタを含んでもよい。
　１つ前のトランザクションとは、鍵のｎ回目の更新を行う鍵更新トランザクションの場合、鍵のｎ－１回目の更新を行ったトランザクションを指す。なお、今回の鍵更新トランザクションが初めて鍵を更新するものである場合、１つ前のトランザクションは、鍵生成トランザクションを指す。鍵更新トランザクションの１つ前のトランザクションも当然さらに１つ前のトランザクションデータのハッシュ値を含む構成である。このように、すべての鍵更新トランザクションは、鍵生成トランザクションまで数珠つなぎとなるデータ構造を有している。そうすると、鍵更新トランザクションは、鍵が生成されたトランザクションから鍵更新トランザクションまでのすべての鍵の更新履歴のハッシュ値を含んでいることになる。鍵更新トランザクションがこのような構成をとることで、途中のトランザクションに改ざんが行われたとしても、検知が容易になる。
　更新済みの鍵のデータは、例えば鍵更新トランザクションにおいて、新たな鍵として承認される更新後の公開鍵のハッシュ値である。なお、更新済みの鍵データは新たな鍵を識別可能な情報であればよく、例えば公開鍵の識別子でもよい。鍵更新トランザクションには、さらに更新後の公開鍵で暗号化された更新後の秘密鍵が含まれてもよい。
　ユーザＡの署名は、更新前後のそれぞれの秘密鍵を用いて生成された署名である。言い換えると、今回（ｎ回目）の更新後の秘密鍵と、前回（ｎ－１回目）の更新後の秘密鍵とを用いて生成された署名である。ただし、鍵更新トランザクションにおいて更新される鍵が、ユーザＡが提供するサービスで利用される鍵等、ユーザＡ自身の署名に用いる鍵とは別の鍵である場合には、ユーザＡは署名用の鍵を用いて署名を生成することも可能である。
　承認者の署名は、ユーザＡ以外の任意の数のユーザが、更新された鍵を承認する際に、自身の秘密鍵を用いて生成した署名である。承認者の署名は、例えば鍵更新トランザクションの起源となる鍵生成トランザクションが有する承認者の署名と同一のユーザの署名である。ただし、これに限定されず、承認者として署名するユーザ及びその数は、鍵更新トランザクションのたびにユーザＡ（鍵の更新者）が選択する構成でもよいし、ランダムに決められる構成でもよいし、更新の回数に応じて署名するユーザをあらかじめアクセス管理システム１の管理者が設定しておく構成でもよい。つまり、鍵更新トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。
　鍵更新トランザクションにおいても、各ユーザの署名は、鍵更新トランザクションのうち、署名を行う領域を除いたデータ（すなわち、「１つ前のトランザクションデータのハッシュ値」と「ユーザＡの更新済みの鍵のデータ（本実施形態では公開鍵のハッシュ値）」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。
　図５は分散型台帳１３１において管理される鍵失効トランザクション（第３トランザクションの一例である。）を含むブロックＢ３の構造の一例を示す図である。鍵失効トランザクションは、アクセス管理システム１において生成した鍵を失効させるトランザクションである。図５では一例として、図３に示した鍵生成トランザクションにおいて生成したユーザＡの鍵を失効させる鍵失効トランザクションを示している。
　鍵失効トランザクションには、例えば、以下のデータが格納されている。
・１つ前のトランザクションデータのハッシュ値
・ユーザＡの鍵の失効情報
・ユーザＡの署名
・他ユーザ（承認者）の署名
　なお、鍵失効トランザクションは、上記の他に、１つ前のトランザクションへのポインタを含んでもよい。
　ユーザＡの鍵の失効情報は、ユーザＡの鍵が失効したことを特定可能な情報である。失効情報は、例えば、鍵の失効日、失効理由等を含む。失効理由は、典型的には鍵の所有者からの申請（秘密鍵の紛失や盗難、サービスの利用停止等）の他、システム管理者による失効登録（利用者の義務違反等）が挙げられる。なお、失効情報には、さらに失効対象となる鍵を識別可能な情報（例えば公開鍵本体と暗号化された秘密鍵等）が含まれてもよい。
　ユーザＡの署名は、例えば、失効対象となる鍵を用いて生成された署名である。ただし、鍵失効トランザクションにおいて失効される鍵が、ユーザＡが提供するサービスで利用される鍵等、ユーザＡ自身の署名に用いる鍵とは別の鍵である場合には、ユーザＡは署名用の鍵を用いて署名を生成することも可能である。なお、失効操作を行うのがユーザＡ以外のユーザ（すなわち失効対象の鍵の所有者以外のユーザ）である場合には、ユーザＡ（鍵の所有者）の署名はなくてもよい。この場合には、鍵失効トランザクションには、ユーザＡの署名の代わりに失効操作者の署名が含まれる。
　承認者の署名は、ユーザＡ以外の任意の数のユーザが、鍵の失効を承認する際に、自身の秘密鍵を用いて生成した署名である。承認者として署名するユーザ及びその数は、鍵更新トランザクションと同様、起源となる鍵生成トランザクションに含まれる承認者の署名と同一のユーザの署名でもよいし、失効者やアクセス管理システム１の管理者が指定してもよいし、ランダムに決められてもよい。つまり、鍵失効トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。
　鍵失効トランザクションにおいても、各ユーザの署名は、鍵更新トランザクションのうち、署名が生成される領域を除いたデータ（すなわち、「１つ前のトランザクションデータのハッシュ値」と「ユーザＡの鍵の失効情報」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。
　図２に戻り、ノード１０の各機能部の詳細について説明する。以下の説明では、鍵生成トランザクション、鍵更新トランザクション、及び鍵失効トランザクションをまとめて単「トランザクション」ともいう。
（２）鍵取得部１１１
　鍵取得部１１１（取得手段の一例である。）は、操作対象となる鍵の情報を取得する。例えば操作が鍵の生成である場合には、鍵取得部１１１は、鍵を生成することができる。生成される鍵は、分散型台帳１３１、及び／又はデータベース３０において、ユーザＡと関連付けられていない鍵である。
　また、操作が鍵の更新である場合には、鍵取得部１１１は、更新後の新たな鍵を生成する。更新後の新たな鍵は、分散型台帳１３１、及び／又はデータベース３０において、ユーザＡと関連付けられていない鍵である。さらに鍵取得部１１１は、データベース３０を参照して、更新対象の鍵を取得する。
　操作が鍵の失効である場合には、鍵取得部１１１は、処理を行わない。ただし、この場合にも、鍵取得部１１１は、データベース３０を参照して失効対象の鍵を取得してもよい。
　なお、鍵取得部１１１はデータベース３０から鍵を取得する際には、操作対象の鍵が承認されたトランザクションのＩＤやユーザＡの識別子に基づいてデータベース３０を検索することができる。また、鍵取得部１１１は、鍵を生成する代わりに、他ノードに鍵の生成を依頼し、他ノードにおいて生成された鍵を取得する構成でもよい。この場合、鍵を生成する他ノードは、例えばアクセス管理システム１の管理ノードであることが好ましい。
（３）鍵検証部１１２
　鍵検証部１１２（検証手段の一例である。）は、鍵取得部１１１が取得した鍵のうち、少なくともユーザＡが新たに使用する鍵について、正常に機能するか検証を行う。例えば鍵検証部１１２は、鍵取得部１１１が生成した鍵ペアや、他ノードに生成を依頼した鍵ペアについて、一方の鍵が暗号化したデータを他方の鍵で復号可能か否かの検証を行う。
（４）トランザクション生成部１１３
　トランザクション生成部１１３（生成手段の一例である。）は、鍵の操作に関するトランザクションを生成する。トランザクションの各構成の生成処理について具体的に説明する。
　まず、トランザクション生成部１１３は、鍵のデータとして、例えば、鍵検証部１１２が検証した公開鍵から所定のハッシュ関数を使ってハッシュ値を生成する。なお、トランザクション生成部１１３は鍵のデータとして、公開鍵の識別子を用いてもよい。また、トランザクションが暗号化された秘密鍵を含む場合には、トランザクション生成部１１３は、秘密鍵に対応する公開鍵もしくは既存の別の公開鍵を用いて、秘密鍵の暗号化を行う。
　次に、トランザクション生成部１１３は、生成するトランザクションが鍵更新トランザクション又は鍵失効トランザクションである場合には、１つ前のトランザクションのハッシュ値を生成する。今回生成するトランザクションの１つ前のトランザクションは、操作（更新・失効）対象の鍵が承認されたトランザクションである。そこでまず、トランザクション生成部１１３は、操作対象となる鍵が承認されたトランザクションＩＤを特定する。例えば、トランザクション生成部１１３は、トランザクションＩＤをユーザＡから指定される構成でもよいし、ユーザＡから更新対象となる鍵の指定を受け付け、データベース３０を参照して、指定された鍵に対応するトランザクションＩＤを特定する構成でもよい。トランザクションＩＤを特定すると、トランザクション生成部１１３は、分散型台帳１３１を参照して、特定したトランザクションＩＤに対応するトランザクションを取得し、当該トランザクションのハッシュ値を算出する。
　なお、生成するトランザクションが鍵失効トランザクションの場合には、トランザクション生成部１１３は、さらに失効情報を生成する。失効情報は、例えばユーザＡからの入力を受付けて生成することができる。
　最後にトランザクション生成部１１３は、ネットワークＮにおいて一意なトランザクションＩＤを採番し、トランザクションを生成する。
（５）署名実行部１１４
　署名実行部１１４は、ユーザＡの署名用の鍵を用いてトランザクションに署名を行う。一例として、署名実行部１１４は、トランザクション生成部１１３が生成したトランザクションのうち、署名が格納される領域を除くデータのハッシュ値を計算し、ダイジェストを生成する。そして、署名実行部１１４は生成したダイジェストをユーザＡの秘密鍵を用いて暗号化することで、署名を行う。ここで署名に用いられる秘密鍵は、例えば鍵生成トランザクションの場合は生成された秘密鍵であり、鍵更新トランザクションの場合は更新前後の秘密鍵であり、鍵失効トランザクションの場合は失効対象の秘密鍵である。なお、トランザクションで操作される鍵と署名を生成する鍵とは必ずしもペアである必要はない。例えば、トランザクションで操作される公開鍵が、ユーザＡの署名用の秘密鍵に対応する公開鍵とは異なる場合には、署名実行部１１４は、ユーザＡの既存の署名用の鍵（すなわちトランザクションで操作される鍵とは異なる鍵）を用いて、生成したダイジェストを暗号化することで署名を生成する。
（６）送信部１１５
　送信部１１５（送信手段の一例である。）は、署名実行部１１５が署名したトランザクションを、承認依頼先のノードに送信する。このとき、送信部１１５は、トランザクションに承認を依頼する（すなわち署名を求める）他ユーザ（承認者）の識別子を宛先に承認依頼先として設定する。例えば送信部１１５は、ノード１０ＡのユーザＡから、承認依頼先の承認者の指定を受け付ける構成でもよいし、アクセス管理システム１の管理者からあらかじめ定められている承認者を設定する構成でもよいし、アクセス管理システム１のユーザからランダムに選択して設定する構成でもよい。
　なお、送信部１１５はトランザクションを承認依頼先に送信する際に、署名実行部１１５が行った署名を復号可能な公開鍵（つまり、新たに生成された公開鍵や、更新後の公開鍵、失効対象となる公開鍵）を併せて送信してもよい。また、送信部１１５は、トランザクションをネットワークＮ全体に送信することも可能である。
（７）データベース制御部１１６
　データベース制御部１１６（共有手段の一例である。）は、鍵検証部１１２が検証した鍵を分散型台帳システムを構成する他のノード（ノード１０Ｂ、１０Ｃ）と共有する。一例として、データベース制御部１１６は、鍵検証部１１２が検証した鍵をデータベース３０に登録する。具体的には、鍵に対する操作が、「生成」である場合には、データベース制御部１１６は、データベース３０に新なレコードを追加して、公開鍵と、当該公開鍵で暗号化された秘密鍵を登録する。
　鍵に対する操作が、「更新」である場合には、データベース制御部１１６は、データベース３０を参照して、更新対象の鍵に対応するレコードを抽出し、抽出したレコードに更新後の公開鍵及び当該公開鍵で暗号化された秘密鍵を追加する。なお、データベース制御部１１６は、更新前の公開鍵及び暗号化された秘密鍵を更新後の公開鍵及び暗号化された秘密鍵に置き換える構成でもよい。
　鍵に対する操作が、「失効」である場合には、データベース制御部１１６は、データベース３０を参照して、失効対象の鍵に対応するレコードを削除する。なお、データベース制御部１１６は、レコードを削除する代わりに抽出したレコードに失効情報を追加する構成でもよい。
　データベース制御部１１６は、データベース３０に対して鍵の登録を行う場合には、鍵と対応付けてトランザクション生成部１１４が生成したトランザクションの識別子（以下「トランザクションＩＤ」ともいう。）をデータベース３０に登録しておくことが好ましい。
　なお、データベース制御部１１６が他のノードと鍵を共有する方法は、データベース３０に登録する方法の他、鍵を直接他のノードに送信する方法でもよい。
　また、本実施形態では、データベース制御部１１６は、送信部１１５がトランザクションを送信する前にデータベース３０に検証された鍵を登録する。この場合、データベース制御部１１６は、送信されたトランザクションが承認者によって承認されなかった場合には、登録内容をロールバックする。ただし、登録処理のタイミングはこれに限定されず、データベース制御部１１６は、データベース制御部１１６は、検証された鍵のデータベース３０への登録処理を、承認者によるトランザクションへの署名が完了した場合に行う構成でもよい。この場合、トランザクションにはユーザＡの署名を復号可能な公開鍵そのものが含まれるか、送信部１１５がトランザクションを送信する際に、データベース制御部１１６があわせて公開鍵を送信することが好ましい。
（８）処理フロー
　図６を参照して、ノード１０Ａが鍵に対して操作を行う際の処理の流れを説明する。図６はノード１０Ａの処理フローの一例を示すフローチャートである。
　まず、鍵取得部１１１は、操作対象となる鍵を取得する（Ｓ１１）。鍵取得部１１１は、操作内容に応じて、鍵を生成したり、データベース３０から検索することで、操作対象となる鍵を取得する。
　次に、鍵検証部１１２が、取得された鍵が正常に機能するか否かの検証を行う（Ｓ１２）。鍵が正常に機能しない場合（Ｓ１３：ＮＯ）には、ノード１０Ａは処理を終了する。なお、このときノード１０Ａはアクセス管理システム１の管理者に通報を行う構成でもよい。
　鍵が正常に機能した場合（Ｓ１３：ＹＥＳ）、トランザクション生成部１１３がトランザクションを生成する。生成されたトランザクションに署名実行部１１４が署名を行う（Ｓ１５）と、送信部１１５は、承認依頼先を設定して、トランザクションを送信する（Ｓ１６）。一方、鍵が正常に機能した場合（Ｓ１３：ＹＥＳ）、データベース制御部１１６は、検証された鍵をデータベース３０に登録する（Ｓ１７）。なお、Ｓ１７の処理と、Ｓ１４乃至Ｓ１６の処理との前後関係は任意である。
　なお、Ｓ１７の処理がＳ１６の処理に前に行われた場合には、データベース制御部１１６は、送信部１１５が送信したトランザクションが承認されなかった場合に、データベース３０をロールバックし、鍵の登録を取り消すことができる。
＜３－２．承認ノード（ノード１０Ｂ、１０Ｃ）＞
　次に、図７を用いて承認ノードであるノード１０Ｂ、１０Ｃの機能構成について説明する。図７は、本実施形態に係るノード１０Ｂの機能ブロック図である。なお、ノード１０Ｃの機能構成はノード１０Ｂと同様であるため説明を割愛する。図７に示すように、ノード１０Ｂは、記憶部１３１と、トランザクション取得部１２１と、トランザクション検証部１２２と、署名実行部１２３と、送信部１２４とを有している。記憶部１３１には、ユーザＢの秘密鍵の他、上述した分散型台帳１３１が記録されている。ただし、すべての承認ノードが分散型台帳１３１を有している必要はなく、一部の承認ノードが有している構成でもよい。
（１）トランザクション取得部１２１
　トランザクション取得部１２１は、ネットワークＮに送信されたトランザクションを取得する。例えばトランザクション取得部１２１は、受信したトランザクションから、自ノード宛に署名依頼がされているトランザクションを抽出することが可能である。
（２）トランザクション検証部１２２
　トランザクション検証部１２２は、取得したトランザクションの正当性の検証を行う。
　例えば、トランザクション検証部１２２は、取得したトランザクションから署名を行う領域を除いたデータからハッシュ値を算出し、復号したダイジェストと突合することでユーザＡの署名を検証する。これによって、操作者がユーザＡであること、及びトランザクションが改ざんされていないことを検証することができる。
　さらにトランザクション検証部１２２は、トランザクションに含まれるユーザＡの署名の検証を行ってもよい。具体的には、トランザクション検証部１２２は、データベース３０を参照し、取得したトランザクションのＩＤに対応するレコードを抽出する。次に抽出したレコードからユーザＡの公開鍵を取得して、ユーザＡの署名からダイジェストを復号する。なお、トランザクションに公開鍵そのものが含まれている場合や、トランザクションに公開鍵が添付されて送信されている場合等には、トランザクション検証部１２２は、必ずしもデータベース３０から公開鍵を検索する必要はない。
　なお、トランザクション検証部１２２は、鍵更新トランザクションの場合には、更新前後の秘密鍵によって行われたそれぞれの署名を検証する。ただし、鍵更新トランザクションにおいて更新される鍵がユーザＡの署名用の鍵とは異なる鍵ペアや共通鍵の場合には、鍵更新トランザクションにはユーザＡの既存の署名用の鍵による署名が含まれることになる。この場合には、トランザクション検証部１２２は、署名用の鍵によって生成されたユーザＡの署名を検証する。また、鍵失効トランザクションであって、失効操作者がユーザＡでない場合には、失効操作者の署名を検証する。
　さらに、トランザクション検証部１２２は、上記の他、トランザクションに含まれるその他のデータが適切か否かを検証してもよい。例えば、鍵更新トランザクションや鍵失効トランザクションの場合、トランザクションに含まれる１つ前のトランザクションのハッシュ値が正しい値であるか否かを、１つ前のトランザクションのハッシュ値を算出して検証してもよい。また、例えば、トランザクションに含まれる鍵のデータが正しいか否かを、データベース３０に登録されているデータと突合して検証してもよい。具体的には、トランザクションに公開鍵のハッシュ値が含まれる場合には、トランザクション検証部１２２は、署名を復号して得た公開鍵のハッシュ値と、データベース３０に登録されている公開鍵からハッシュ値を算出し、突合することができる。
（３）署名実行部１２３
　署名実行部１２３は、トランザクション検証部１２２が正当性を検証したトランザクションについて、ユーザＢが承認依頼先として指定されているトランザクションである場合には、ユーザＢの署名用の鍵を用いてトランザクションに署名を行う。他方、ユーザＢが署名を求められていないトランザクションである場合には、処理を行わない。
（４）送信部１２４
　送信部１２４は、署名実行部１２３が署名したトランザクションを送信する。このとき、送信部１２４は、ノード１０ＡのユーザＡから、署名を依頼した承認者のうち、未署名のユーザがいる場合には、当該未署名のユーザ宛にトランザクションを転送する構成でもよいし、未署名のユーザの有無にかかわらず、ユーザＡにトランザクションを返送する構成でもよい。
　さらに送信部１２４は、トランザクション取得部１２１が取得したトランザクションにおいて、未署名のユーザがいなかった場合には、ネットワークＮ全体にトランザクションを送信することで、ネットワークＮに接続するノード１０の分散型台帳１３１にトランザクションを登録することも可能である。
（５）処理フロー
　図８を参照して、ノード１０Ｂがトランザクションを承認する際の処理の流れを説明する。図８はノード１０Ｂの処理フローの一例を示すフローチャートである。
　まず、トランザクション取得部１２１は、ネットワークＮからトランザクションを取得する（Ｓ２１）。次に、トランザクション検証部１２２が、取得したトランザクションの検証を行う（Ｓ２２）
　検証の結果、トランザクションが否認されるべきと判断された場合（Ｓ２３：ＮＯ）には、ノード１０Ｂは処理を終了する。なお、このときノード１０Ｂはアクセス管理システム１の管理者に通報を行う構成でもよい。
　他方、検証の結果、トランザクションが承認されるべきと判断された場合（Ｓ２３：ＹＥＳ）、であって、承認依頼先にノードＢが指定されている場合（Ｓ２４：ＹＥＳ）には、署名実行部１２３がユーザＢの秘密鍵を用いて署名を行う（Ｓ２５）。
　最後に、送信部１２４が、トランザクションを送信する（Ｓ２６）。このとき送信部１２４は、承認依頼先に設定されているユーザに、未承認のユーザがいる場合には、当該未承認のユーザ又はユーザＡにトランザクションを送信する。他方、未承認のユーザがいない場合には、各ノード１０にネットワークＮ全体に送信する。
＜４．利用例＞
　図９を参照して、アクセス管理システム１において管理される鍵の利用方法の一例について説明する。図９は、当該鍵を使ったアクセス制御の仕組みを説明するための模式図である。図９の例では、ノード１０Ａがノード１０Ｂの管理するデータ等にアクセスを行う際に、ノード１０Ａを利用するユーザＡを、ノード１０Ｂが認証（本人確認）する場合を示している。
　まずノード１０Ｂは、ランダムに生成したメッセージ（平文）をノード１０Ａに送信する。なお、メッセージは、一時的に生成した本人確認用の任意のデータを意味する。ノード１０Ａは、受信したメッセージ本文（平文）に対して、ハッシュ関数を使ってハッシュ値（メッセージダイジェスト）を求める（矢印（１））。次に、そのメッセージダイジェストを、記憶部１３０に記憶しているユーザＡの秘密鍵で暗号化する(矢印（２））。ノード１０Ａは、メッセージに、署名に利用した秘密鍵に対応する公開鍵を識別する情報（例えば公開鍵のハッシュ値や識別子（ＩＤ）である。以下では、公開鍵を識別する情報を「公開鍵ＩＤ」ともいう。）を添付し（矢印（３））、ノード１０Ｂに送信する（矢印（４））。なお、公開鍵ＩＤの代わりに、当該の公開鍵を登録したトランザクションＩＤや公開鍵そのものあるいはトランザクションのデータそのものをメッセージに添付する方法も考えられる。
　一方、メッセージを受信したノード１０Ｂは、分散型台帳１３１を参照して、メッセージに添付された公開鍵ＩＤに基づいて、当該公開鍵ＩＤに対応する公開鍵への操作を承認したトランザクションを検索し、抽出する。さらにノード１０Ｂは、抽出したトランザクションを検証する。ここでの検証処理は、上述したトランザクション検証部１２２の検証処理と同様である。
　なお、このとき、ノード１０Ｂは、抽出したトランザクションのあとに、メッセージに添付された公開鍵ＩＤに対応する鍵をさらに更新又は失効させるトランザクションが、分散型台帳１３１に含まれるか否かを判定することが好ましい。具体的には、ノード１０Ｂは、抽出したトランザクション（すなわちメッセージに添付された公開鍵ＩＤに対応する鍵への操作を承認したトランザクション）のハッシュ値を含むトランザクションが分散型台帳１３１に登録されているか否かを判定する。抽出したトランザクションのハッシュ値を含むトランザクションが分散型台帳１３１に登録されている場合には、メッセージに添付された公開鍵ＩＤに対応する公開鍵はすでに失効していることになる。この場合には、ノード１０Ｂは、ユーザＡの署名が不正なものであると判断し、ユーザＡを認証しないことが好ましい。
　なお、ノード１０Ｂが、抽出したトランザクションのハッシュ値を含むトランザクションについて、さらにそのハッシュ値を含むトランザクションが分散型台帳１３１に存在するか否かを繰り返し検証することにより、ユーザＡの最新の鍵の情報を確認することができる。
　ノード１０Ｂは、抽出したトランザクションにおける承認者を特定し、データベース３０を参照して特定した承認者の公開鍵を取得する。取得した承認者の公開鍵を用いて、特定したトランザクションに含まれる承認者の署名を検証し、承認者の正当性を確認する（矢印（５））。つまり、この例では、ユーザＡの公開鍵が承認されたトランザクションがデジタル証明書の代わりとしてユーザＡの公開鍵の正当性（信頼性）を証明しているといえる。
　なお、ノード１０Ｂが、さらに、特定したトランザクションに含まれるユーザＡの公開鍵のハッシュ値（公開鍵ＩＤ）と、データベース３０から取得したユーザＡの公開鍵にハッシュ関数を用いて求めたハッシュ値とを比較して、トランザクションＩＤが今回用いられている秘密鍵を承認するためのものであったかを確認する構成も可能である。
　さらにノード１０Ｂは、ユーザＡの公開鍵を用いてユーザＡの署名を復号する（矢印（６））とともに、メッセージ本文（平文）からノード１０Ａと同じハッシュ関数を使ってハッシュ値（メッセージダイジェスト）を求め（矢印（７））、両者を突合してチェックする（矢印（８））ことでユーザＡを認証する。なお、トランザクションが公開鍵そのものを含む構成の場合には、ノード１０Ｂは特定したトランザクションからユーザＡの公開鍵を取得することが可能である。
　このように、本実施形態に係るアクセス管理システム１によると、ユーザは使用する鍵が１以上のユーザから承認されたトランザクションによって、ユーザの鍵の正当性（信頼性）を証明することができる。すなわち、ユーザの鍵の信頼性をユーザ相互に担保することが可能となるため、仮に、あるユーザの信頼性が損なわれた場合でも承認者の信頼性に基づいてシステム全体の信頼性を継続することができる。さらに、鍵の失効についてもユーザ相互で承認することで、従来のＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）による一元管理が不要になる。
＜ハードウェア構成＞
　以下、図１０を参照しながら、第１の実施形態及び第２の実施形態において上述してきたノード１０、及びデータベース３０をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。
　図１０に示すように、コンピュータ８００は、プロセッサ８０１、メモリ８０３、記憶装置８０５、入力Ｉ／Ｆ部８０７、データＩ／Ｆ部８０９、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。
　プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、ノード１０Ａ、１０Ｂの鍵取得部１１１や、鍵検証部１１２、データベース制御部１１６、トランザクション生成部１１４、署名実行部１１５、トランザクション取得部１２１、トランザクション検証部１２２、署名実行部１２３、送信部１２４、などは、メモリ８０３に一時記憶された上で、主にプロセッサ８０１上で動作するプログラムとして実現可能である。
　メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。
　記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、分散型台帳１３１を記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。
　入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。
　データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。
　通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。
　表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブル等を介してコンピュータ８００に接続される。
[その他の実施形態]
　以上説明した各実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更／改良され得るととともに、本発明にはその等価物も含まれる。また、各実施形態は例示であり、異なる実施形態で示した構成の部分的な置換または組み合わせが可能であることは言うまでもなく、これらも本発明の特徴を含む限り本発明の範囲に包含される。
　例えば、既述の実施形態において、トランザクションに対してマイニングは行われない例を説明したが、これに限定されず、ＰｏＷの技術を用いてマイニングを行ったうえで、トランザクションを分散型台帳１３１に登録する構成でもよい。
　また、既述の実施形態において、トランザクションにおいて操作が承認されるユーザＡの鍵と、当該トランザクションに署名を生成するユーザＡの鍵とは対となる構成について説明した。しかしこれに限定されず、トランザクションでは、ユーザＡが署名を生成する鍵（例えば署名用の秘密鍵である。）とは異なる鍵ペアに対する操作が承認されてもよい。この場合、トランザクションには、当該トランザクションによって操作が承認される公開鍵とは異なる、既存の公開鍵と対になる秘密鍵による署名や、既存の公開鍵で暗号化された秘密鍵が含まれてもよい。トランザクション生成部１１３は、このようなトランザクションを生成するにあたり、操作対象となる公開鍵を識別する情報（ハッシュ値やＩＤ）や、操作対象となる公開鍵とは異なる既存の公開鍵で暗号化された秘密鍵を用いることができる。また、このとき署名実行部１１４は、トランザクションによって操作が承認される公開鍵とは異なる、既存の公開鍵と対になる秘密鍵によってトランザクションにユーザＡの署名を生成する。さらに、この場合には、トランザクション検証部１２２は、トランザクション検証部１２２は、生成されたユーザＡの署名を、署名を行った秘密鍵と対となるユーザＡの既存の公開鍵を用いて検証する。
　さらに、既述の実施形態では、アクセス管理システム１は、公開鍵暗号方式に基づく鍵ペアを管理する例について説明したが、これに限定されず、共通鍵暗号方式に基づく共通鍵を管理する構成でもよい。この場合、トランザクションには、共通鍵のハッシュ値、または既存の公開鍵で暗号化された共通鍵そのものや、ユーザＡの署名用の鍵による署名が含まれる。なお、ここでいう署名用の鍵は、公開鍵暗号方式の秘密鍵だけでなく、メッセージ認証符号（ＭＡＣ値）の生成・復号を行う認証用の共通鍵も含む。共通鍵の場合、署名はメッセージ認証符号（ＭＡＣ値）を指す。トランザクション生成部１１３は、このようなトランザクションを生成するにあたり、操作対象となる共通鍵を識別する情報（ハッシュ値やＩＤ）を用いることができる。また、このとき署名実行部１１４は、トランザクションによって操作が承認される共通鍵、当該共通鍵とは異なる認証用の共通鍵、または既存の署名用の公開鍵と対になる秘密鍵によってトランザクションにユーザＡの署名またはＭＡＣ値を生成する。さらに、この場合には、トランザクション検証部１２２は、トランザクション検証部１２２は、生成されたユーザＡの署名を、今回操作対象となる共通鍵や、ユーザＡの認証用の共通鍵、署名用の公開鍵を用いて検証する。
１　アクセス管理システム
１０Ａ、１０Ｂ、１０Ｃ　ノード
３０　データベース
１１１　鍵取得部
１１２　鍵検証部
１１３　トランザクション生成部
１１３　データベース制御部
１１４　署名実行部
１１５　送信部
１１６　データベース制御部
１２１　トランザクション取得部
１２２　トランザクション検証部
１２３　署名実行部
１２４　送信部
１３０　記憶部
１３１　分散型台帳

Claims (6)

  1. 　トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、
    　第１ユーザのアクセス権限を示すための第１鍵であって、前記分散型データベースにおいて前記第１ユーザに関連づけられていない第１鍵を取得する取得手段、
    　前記第１鍵の検証を行う検証手段、
    　前記第１鍵に関する情報を、前記分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、
    　前記第１鍵の情報と、前記第１ユーザのデジタル署名とを含み、前記第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び
    　前記第１トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第１トランザクションを前記１以上の第２ユーザのコンピュータに送信する送信手段、
    として機能させるプログラム。
  2. 　前記取得手段は、さらに、
    　　前記第１鍵に代えて第１ユーザのアクセス権限を示す第２鍵であって、前記分散型データベースにおいて前記第１ユーザに関連付けられていない第２鍵を取得し、
    　前記検証手段は、さらに、
    　　前記第２鍵の検証を行い、
    　前記共有手段は、さらに、
    　　前記第２鍵に関する情報を、前記１以上の第２ユーザのコンピュータと共有し、
    　前記生成手段は、さらに、
    　　前記第１鍵を用いて生成されたデジタル署名と、前記第２鍵を用いて生成されたデジタル署名と、前記第１トランザクションのハッシュ値とを含み、前記第２鍵の使用の承認を依頼する第２トランザクションを生成し、
    　前記送信手段は、さらに、
    　　前記第２トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第２トランザクションを前記１以上の第２ユーザのコンピュータに送信する送信手段、
    請求項１に記載のプログラム。
  3. 　前記生成手段は、さらに、
    　前記第１鍵が失効することを示す情報と、前記第１トランザクションのハッシュ値と、前記第１ユーザのデジタル署名とを含み、前記第１鍵の失効の承認を依頼する第３トランザクションを生成し、
    　前記送信手段は、さらに、
    　前記第３トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第３トランザクションを前記１以上の第２ユーザのコンピュータに送信する
    　請求項１または２に記載のプログラム。
  4. 　ユーザのアクセス権限を示す鍵への操作を承認するためのトランザクションが管理される分散型データベースと、
    　前記分散型データベースにアクセス可能な第１ノード及び１以上の第２ノードと、
    　を備え、
    　前記第１ノードは、
    　　第１ユーザのアクセス権限を示すための第１鍵であって、前記分散型データベースにおいて前記第１ユーザに関連付けられていない第１鍵を取得する取得部と、
    　　前記第１鍵の検証を行う検証部と、
    　　前記第１鍵に関する情報を、前記第２ノードと共有する共有部と、
    　　前記第１鍵の情報と、前記第１ユーザのデジタル署名とを含み、前記第２ノードに前記第１鍵の使用の承認を依頼する第１トランザクションを生成する生成部と、
    　前記第１トランザクションを、前記第２ノードに送信する送信部と、
    を有し、
    　前記第２ノードは、
    　　共有された前記第１鍵に関する情報と前記第１ユーザのデジタル署名に基づいて、前記第１トランザクションの正当性を検証する検証部と、
    　　正当性が検証された前記第１トランザクションに対して、第２ユーザのデジタル署名を生成する署名部と、
    　　前記第１トランザクションを前記分散型データベースに送信する送信部と、
    を有する
    アクセス管理システム。
  5. 　メッセージ本体と、
    　前記メッセージ本体から所定のハッシュ関数に基づいて算出したダイジェストを、第１暗号化鍵を用いて暗号化した第１デジタル署名と、
    　前記第１暗号化鍵によって暗号化されたデータを復号する第１復号鍵を識別する第１情報を含む証明書データと、
    を含むメッセージのデータ構造であって、
    　前記メッセージを受信したノードが、
    　　前記ノードがアクセス可能な分散型台帳において、前記証明書データに含まれる前記第１情報に基づいて前記第１復号鍵の使用が承認されたトランザクションを特定し、
    　　当該トランザクションにおいて前記第１復号鍵の使用を承認した、複数のユーザそれぞれの第２暗号化鍵による複数の第２デジタル署名を、前記複数のユーザそれぞれの第２暗号化鍵によって暗号化されたデータを復号する第２復号鍵によって検証し、
    　　前記第１復号鍵によって前記第１デジタル署名から前記ダイジェストを復号し、前記メッセージ本体から前記所定のハッシュ関数に基づいてダイジェストを算出し、復号した前記ダイジェストと突合して前記第１暗号化鍵の所有者を認証する処理に用いられる
    データ構造。
  6. 　前記ノードは、さらに、
    　　前記分散型台帳において、特定した前記トランザクションのハッシュ値を含む他のトランザクションが登録されている場合には、前記第１暗号化鍵の所有者を認証しない、
    請求項５に記載のデータ構造。
PCT/JP2018/006358 2018-02-22 2018-02-22 アクセス管理システム、及びそのプログラム WO2019163040A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020501912A JP6976405B2 (ja) 2018-02-22 2018-02-22 アクセス管理システム、及びそのプログラム
PCT/JP2018/006358 WO2019163040A1 (ja) 2018-02-22 2018-02-22 アクセス管理システム、及びそのプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/006358 WO2019163040A1 (ja) 2018-02-22 2018-02-22 アクセス管理システム、及びそのプログラム

Publications (1)

Publication Number Publication Date
WO2019163040A1 true WO2019163040A1 (ja) 2019-08-29

Family

ID=67687158

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/006358 WO2019163040A1 (ja) 2018-02-22 2018-02-22 アクセス管理システム、及びそのプログラム

Country Status (2)

Country Link
JP (1) JP6976405B2 (ja)
WO (1) WO2019163040A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110852745A (zh) * 2019-10-12 2020-02-28 杭州云象网络技术有限公司 一种区块链分布式动态网络密钥自动更新方法
CN114024771A (zh) * 2021-12-27 2022-02-08 四川旷谷信息工程有限公司 一种用于城市轨道交通安防系统的跨级管控方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001520483A (ja) * 1997-10-14 2001-10-30 サーティコム コーポレーション 鍵認証方式
JP5858506B1 (ja) * 2015-04-09 2016-02-10 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法
WO2018016160A1 (ja) * 2016-07-21 2018-01-25 株式会社日立製作所 署名検証システム、署名検証方法及び記憶媒体

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001520483A (ja) * 1997-10-14 2001-10-30 サーティコム コーポレーション 鍵認証方式
JP5858506B1 (ja) * 2015-04-09 2016-02-10 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法
WO2018016160A1 (ja) * 2016-07-21 2018-01-25 株式会社日立製作所 署名検証システム、署名検証方法及び記憶媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YOSHIKI ET AL: "examination of certificate management in consortium chains", PROCEEDING OF THE 2017 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY, 24 January 2017 (2017-01-24) *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110852745A (zh) * 2019-10-12 2020-02-28 杭州云象网络技术有限公司 一种区块链分布式动态网络密钥自动更新方法
CN110852745B (zh) * 2019-10-12 2022-07-19 杭州云象网络技术有限公司 一种区块链分布式动态网络密钥自动更新方法
CN114024771A (zh) * 2021-12-27 2022-02-08 四川旷谷信息工程有限公司 一种用于城市轨道交通安防系统的跨级管控方法

Also Published As

Publication number Publication date
JP6976405B2 (ja) 2021-12-08
JPWO2019163040A1 (ja) 2021-01-07

Similar Documents

Publication Publication Date Title
US11196573B2 (en) Secure de-centralized domain name system
US10708047B2 (en) Computer-readable recording medium storing update program and update method, and computer-readable recording medium storing management program and management method
JP5749236B2 (ja) 鍵付け替え管理装置および鍵付け替え管理方法
KR101985179B1 (ko) 블록체인 기반의 ID as a Service
JP2020010267A (ja) 分散型医療情報共有システム、医療情報提供サーバー及びプログラム
JP6543743B1 (ja) 管理プログラム
US20190020648A1 (en) Systems and methods for managing device association
US11722303B2 (en) Secure enclave implementation of proxied cryptographic keys
JP2007226470A (ja) 権限管理サーバ、権限管理方法、権限管理プログラム
EP4096160A1 (en) Shared secret implementation of proxied cryptographic keys
JP5012574B2 (ja) 共通鍵自動共有システム及び共通鍵自動共有方法
JP6976405B2 (ja) アクセス管理システム、及びそのプログラム
JPH05298174A (ja) 遠隔ファイルアクセスシステム
JP6939313B2 (ja) 分散認証システム
JP2009212625A (ja) 会員認証システム及び携帯端末装置
JP4552785B2 (ja) 暗号化通信管理サーバ
JP4641148B2 (ja) 個人情報開示システム、個人情報開示方法および個人情報開示プログラム
JP2003244123A (ja) 共通鍵管理システム、共通鍵管理サーバ、共通鍵管理方法、及び共通鍵管理プログラム
JP5665592B2 (ja) サーバ装置並びにコンピュータシステムとそのログイン方法
JPH11331145A (ja) 情報共有システム、情報保管装置およびそれらの情報処理方法、並びに記録媒体
JP6524556B2 (ja) 認証鍵複製システム
KR100834576B1 (ko) Ｐ２ｐ 네트워크에서 보안통신을 위한 키 관리 방법 및이를 위한 장치
KR102497440B1 (ko) Did 기반의 사용자 정보 관리 서비스 제공 방법 및 시스템
JP7230293B2 (ja) 管理サーバ、管理システム、管理方法、及びプログラム
KR20230080676A (ko) 고속 블록체인 네트워크를 이용한 did 관리 시스템 및 방법

Legal Events

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

Ref document number: 18907035

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020501912

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 10/11/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18907035

Country of ref document: EP

Kind code of ref document: A1