WO2018016160A1 - 署名検証システム、署名検証方法及び記憶媒体 - Google Patents

署名検証システム、署名検証方法及び記憶媒体 Download PDF

Info

Publication number
WO2018016160A1
WO2018016160A1 PCT/JP2017/018291 JP2017018291W WO2018016160A1 WO 2018016160 A1 WO2018016160 A1 WO 2018016160A1 JP 2017018291 W JP2017018291 W JP 2017018291W WO 2018016160 A1 WO2018016160 A1 WO 2018016160A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
public
signature
transaction
key
Prior art date
Application number
PCT/JP2017/018291
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 SG11201900414WA priority Critical patent/SG11201900414WA/en
Priority to US16/318,501 priority patent/US11018876B2/en
Publication of WO2018016160A1 publication Critical patent/WO2018016160A1/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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—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 involving digital signatures

Definitions

  • the present invention relates to a block chain (signature verification) system for realizing distributed ledger management on a peer-to-peer (P2P) network.
  • P2P peer-to-peer
  • a block chain there is a system that forms a chain by a user who guarantees recorded information, such as Bitcoin disclosed in Non-Patent Document 1, by giving an electronic signature to a transaction with his / her private key.
  • NAKAMOTO “Satoshi”, “Bitcoin:“ A peer-to-peer ”electronic cash system.”, Published in 2008
  • a user In a blockchain system, a user generates a transaction by generating an electronic signature using his / her private key. If the private key is lost, the correct transaction cannot be generated and the system is continuously It becomes difficult to use. Further, when the secret key is stolen, a third party who has acquired the secret key can illegally generate a transaction and impersonate it.
  • a self-evident and effective solution to such a problem is a method of managing confidential information in a form that is unlikely to be lost or stolen.
  • a biometric signature disclosed in Patent Document 1 as a method for realizing public key encryption based on information that is unlikely to be lost or stolen.
  • the biometric signature is a technique for realizing signature generation and signature verification for a message using biometric information represented by fingerprints, veins, faces, and the like as keys. Since biometric information is obtained by sensing human physical characteristics, it is less likely to be lost or stolen than a public key cipher secret key known or publicly known.
  • An object of the present invention is to realize a system that enables continuous transaction generation even when a private key is lost or leaked without reducing user convenience.
  • the present invention relates to a signature verification system that verifies a signature with a computer having a processor and a memory, a biometric information acquisition unit that acquires biometric information of a user, and a public template certificate by performing predetermined processing on the biometric information
  • a verification unit that verifies the signature with a key certificate.
  • the user when a user's existing private key is lost or leaked, the user can issue a public key revocation application to invalidate transaction generation using the existing private key, and Generate a new public key certificate by generating a pair of a private key and a new public key, assigning a biometric signature to the new public key using the biometric information as a key, and then using the new secret key for transactions
  • the signature verification system can be used continuously without using the existing secret key.
  • Example 1 of this invention is a block diagram which shows an example of a block chain system. It is Example 1 of this invention, and is a flowchart which shows the process sequence of issue of a public template certificate. It is Example 1 of this invention, and is a flowchart which shows the process sequence of initial registration. It is Example 1 of this invention, and is a flowchart which shows the process sequence of the transaction production
  • Example 1 of this invention is a flowchart which shows the process sequence of key reissue. It is a figure which shows Example 1 of this invention and shows the data structure of a public template certificate. It is a figure which shows Example 1 of this invention and shows the data structure of a public key certificate. It is a figure which shows Example 1 of this invention and shows the data structure of a public key revocation application. It is a figure which shows Example 1 of this invention and shows the data structure of a certificate revocation list. It is a figure which shows Example 1 of this invention and shows the data structure of the block chain using a biometric signature.
  • Example 1 is a block diagram illustrating a hardware configuration of a signing terminal, a verification terminal, and a public template repository according to a first embodiment of this invention.
  • Example 2 of this invention is a block diagram which shows an example of a block chain system.
  • Example 2 of this invention is a flowchart which shows the process sequence of issue of a public template certificate.
  • Example 2 of this invention is a flowchart which shows the process sequence of public key revocation.
  • Example 2 of this invention shows the data structure of a public key certificate.
  • Example 2 of this invention shows the data structure of a public key revocation application.
  • Example 3 of this invention is a block diagram which shows an example of a block chain system.
  • FIG. 10 is a sequence diagram illustrating an example of registration processing performed in the block chain system according to the third embodiment of this invention.
  • FIG. 10 is a sequence diagram illustrating an example of transaction verification processing performed in the block chain system according to the third embodiment of this invention.
  • FIG. 10 is a sequence diagram illustrating an example of a key reissue process performed in the block chain system according to the third embodiment of this invention.
  • the secret key is revoked (invalidated) by using a biometric signature with the user's biometric information as a key.
  • a new secret key is reissued and the block chain system can be used continuously.
  • FIG. 1 is a block diagram showing an example of the configuration of the block chain system according to the first embodiment of the present invention.
  • the block chain system includes a signing terminal 1000, a verification terminal 11000, a public template repository 1200, a user terminal 1300, and a network 100 that connects these terminals to each other.
  • a signature terminal 1000 includes a communication unit 1010, a biometric information acquisition unit 1020, a public template generation unit 1030, a key pair generation unit 1040, a public key certificate generation unit 1050, and a recording information acquisition unit 1060.
  • the communication unit 1010 performs communication between the verification terminal 1100 and the public template repository 1200 via the network 100.
  • the biometric information acquisition unit 1020 acquires biometric information such as a fingerprint, a vein, and a face image from a user via, for example, a fingerprint sensor, a vein sensor, a camera, and the like.
  • a fingerprint sensor, a vein sensor, or a camera of a mobile phone or a smartphone can be used as a sensor that acquires biometric information.
  • the public template generation unit 1030 generates a public template by performing unidirectional (irreversible) conversion on the biological information acquired by the biological information acquisition unit 1020 according to the method of Patent Document 1.
  • unidirectional conversion a known or well-known conversion process may be applied.
  • the key pair generation unit 1040 generates a private key / public key pair using publicly known or public key cryptography (RSA, DSA, etc.).
  • the public key certificate generation unit 1050 gives the public key certificate to the public key generated by the key pair generation unit 1040 by giving a biometric signature using the biometric information acquired by the biometric information acquisition unit 1020 as a key. Generate.
  • the recording information acquisition unit 1060 acquires recording information to be written in the transaction from an input from an input device.
  • the hash value generation unit 1061 generates a hash value by inputting the recording information and other information acquired by the recording information acquisition unit 1060 to a predetermined hash function.
  • the signature generation unit 1070 generates a signature value for the hash value generated by the hash value generation unit 1061 using a secret key.
  • the new transaction generation unit uses the public key certificate generated by the public key certificate generation unit 1050, the public template certificate (described later), the recording information acquired by the recording information acquisition unit 1060, and the hash value generation unit 1061. A new transaction including the generated hash value and the signature generated by the signature generation unit 1070 is generated.
  • the public key revocation application generation unit 1080 generates a public key revocation application form from the public key certificate generated by the public key certificate generation unit 1050.
  • the verification terminal 1100 includes a communication unit 1110, a public key certificate verification unit 1120, a hash value generation unit 1161, and a signature verification unit 1140.
  • the public key certificate verification unit 1120 verifies the validity of the public key certificate generated by the public key certificate generation unit 1050 of the signing terminal 1000 using a public template.
  • the signature verification unit 1140 verifies the validity of the signature value generated by the signature generation unit 1070 of the signature terminal 1000 using the public key certificate.
  • the communication unit 1110 performs communication between the signature terminal 1000 and the public template repository 1200 via the network 100.
  • the public template repository 1200 includes a communication unit 1210, a public template certificate generation unit 1220, a public key revocation application verification unit 1230, a certificate revocation list generation unit 1240, and a public template certificate storage unit 1290.
  • the certificate revocation list storage unit 1291 is included.
  • the public template certificate generation unit 1220 generates a public template certificate from the public template generated by the public template generation unit 1030 of the signature terminal 1000.
  • the public key revocation application verification unit 1230 validates the public key revocation application generated by the public key revocation application generation unit 1080 of the signing terminal 1000 using the public template certificate generated by the public template certificate generation unit 1220. Verify sex.
  • the certificate revocation list generation unit 1240 generates a certificate revocation list 9300 (FIG. 9D) based on the public key revocation application generated by the public key revocation application generation unit 1080 of the signing terminal 1000.
  • the public template certificate storage unit 1290 stores the public template certificate generated by the public template certificate generation unit 1220.
  • the certificate revocation list storage unit 1291 stores the certificate revocation list 9300 generated by the certificate revocation list generation unit 1240.
  • the communication unit 1210 performs communication between the signature terminal 1000 and the verification terminal 1100 via the network 100.
  • the user terminal 1300 is a computer used by the user B, and is a transmission destination to which the user A using the signature terminal 1000 transmits a transaction.
  • the user terminal 1300 is a computer having a configuration similar to that of the signature terminal 1000.
  • FIG. 2 is a flowchart showing a procedure for initial registration of a public template certificate according to the first embodiment of the present invention.
  • This process is a process in which the block terminal system can be used after the signing terminal 1000 obtains biometric information from the user and the public template repository 1200 generates a public template certificate.
  • each procedure will be described.
  • Initial registration is performed at the signing terminal 1000 (S2010). A specific procedure for initial registration will be described later with reference to FIG. A public template is generated by this procedure.
  • the signing terminal 1000 transmits the public template to the public template repository 1200 (S2020). At this time, the signature terminal 1000 simultaneously transmits information necessary for generating the public template certificate, such as a user name and a biometric signature algorithm used for generating the public template. In order to prevent tampering, a biometric signature may be assigned to the information.
  • the public template repository 1200 receives the public template (S2110) and issues a serial number for the received public template (S2120).
  • the serial number is a number uniquely assigned to the public template, and is managed by the public template repository 1200 so as not to overlap.
  • the public template repository 1200 adds a signature to the public template, and generates and registers a public template certificate (S2130).
  • the data structure of the public template certificate will be described later with reference to FIG. 9A.
  • the public template repository 1200 functions as a reliable third-party organization and is not fraudulent.
  • the signature for the public template is generated using the private key of the certificate authority stored in the public template repository 1200.
  • the public template repository 1200 transmits the public template certificate generated in step S2130 to the signing terminal 1000 (S2140), and the signing terminal 1000 receives the public template certificate (S2030).
  • the signing terminal 1000 stores the public template certificate received in step S2030 in the public template certificate storage unit 1092 (S2040).
  • the biometric information acquisition unit 1020 of the signing terminal 1000 acquires the biometric information of the user (S3010).
  • a biometric sensor such as a fingerprint sensor, a vein sensor, or a camera is connected to the signature terminal 1000. Using these sensors, the biometric information acquisition unit 1020 acquires biometric information such as a user's fingerprint, vein, and facial image. To do.
  • the public template generation unit 1030 generates a public template by performing unidirectional conversion on the biological information acquired in step S3010 (S3020). For this conversion, a biometric encryption method is adopted in which unique data is generated by correcting an error included in biometric information, and encryption processing is performed using the obtained data as a key. As a method that can be used for this conversion, there are, for example, Fuzzy Commitment, Fuzzy Vault, and a biometric signature disclosed in Patent Document 1. In the following description, the biometric signature disclosed in Patent Document 1 is assumed.
  • a public template is generated by performing one-way conversion on biometric information. Even if a third party acquires a public template, it is very difficult to restore biometric information, and it can be handled as public information in the same way as a public key.
  • the key pair generation unit 1040 of the signing terminal 1000 generates a private key / public key pair (S3030). This key pair is generated based on public key encryption such as publicly known or well-known RSA encryption, DSA encryption, Elgamal encryption.
  • the public key certificate generation unit 1050 of the signing terminal 1000 generates a public key certificate by giving a biometric signature using the biometric information acquired in step S3010 as a key to the public key obtained in step S3030. (S3040).
  • the data structure of the public key certificate will be described later with reference to FIG. 9B.
  • the signing terminal 1000 stores the private key generated in step S3030 and the public key certificate generated in step S3040 in the key storage unit 1091 (S3050).
  • step S2010 the key pair and the public key certificate are generated, and the initial registration process in step S2010 is completed.
  • FIG. 4 is a diagram showing a transaction generation and verification procedure in the block chain system, which is performed after the initial registration shown in FIG. 2 is completed.
  • a new transaction is generated for the existing transaction, and the validity of the new transaction is verified in the verification terminal 1100.
  • the procedure will be described with reference to the drawings.
  • the signing terminal 1000 receives the existing transaction (S4010).
  • the existing transaction is a transaction generated in the past in the block chain system, and is located immediately before a new transaction to be generated.
  • the existing transaction is a transaction indicating remittance from another person to itself
  • the new transaction is a transaction for remitting the repaid virtual currency to another person.
  • the existing transaction is acquired from the network (P2P network) 100 via the communication unit 1010.
  • the existing transaction may be acquired by collecting the existing transaction in advance and reading it from the recording device in the signature terminal 1000.
  • the signing terminal 1000 generates a new transaction as a transaction connected next to the existing transaction received in step S4010 (S4011).
  • the detailed procedure for generating a new transaction will be described later with reference to FIG.
  • the signing terminal 1000 transmits the existing transaction received in step S4010 and the new transaction generated in S4011 to the verification terminal 1100 using the communication unit 1010 (S4030).
  • the verification terminal 1100 receives the existing transaction and the new transaction transmitted in step S4030 using the communication unit 1110 (S4210).
  • the signature terminal 1000 and the verification terminal 1100 directly communicate with each other to exchange necessary data.
  • the signature terminal 1000 and the verification terminal 1100 are a large number of terminals. Is connected to the network 100, and data is transmitted and received via other terminals.
  • the verification terminal 1100 verifies the validity of the transaction using the public template certificate included in the existing transaction (S4220). In the transaction verification, it is determined that there is no inconsistency between the contents of the existing transaction and the new transaction, and that the transaction is surely generated by a legitimate user. The detailed procedure of transaction verification will be described later with reference to FIG.
  • the verification terminal 1100 performs conditional branching based on the transaction verification result (S4230), and approves the new transaction only when the verification result is successful (S4240).
  • Transaction approval is a process in which the verification terminal 1100 recognizes that the new transaction is appropriate, and the specific procedure differs depending on the target blockchain system. For example, in the case of bitcoin, which is one of virtual currencies using a block chain, a block is generated by adding a header after collecting approved new transactions.
  • FIG. 5 is a flowchart showing a processing procedure for generating a new transaction (S4020) according to the first embodiment of the present invention. Hereinafter, the procedure will be described with reference to the drawings.
  • the signing terminal 1000 acquires recording information (message) to be included in the new transaction (S5010).
  • the record information is information to be approved in the blockchain system. For example, in the case of virtual currency, it is a currency transaction between users, and in the case of a smart contract, it is contract content.
  • the hash value generation unit 1061 of the signing terminal 1000 generates a hash value of information included in the new transaction (S5020).
  • the new transaction generation unit 1071 of the signature terminal 1000 activates the secret key stored in the key storage unit 1091 in order to give a signature (S5030).
  • the key storage unit 1091 is an auxiliary storage device in the signature terminal 1000
  • the secret key is activated by reading the secret key data from the auxiliary storage device to the main storage device.
  • the secret key is encrypted with a password
  • the password is accepted from the user, and the secret key is extracted after being decrypted.
  • the secret key is stored in a smart device such as an IC card, the secret key is activated by inputting the password to the smart device.
  • the signature generation unit 1070 of the signature terminal 1000 adds a signature to the hash value generated in step S5020 using the private key activated in step S5030 (S5040).
  • the signature generation unit 1070 performs signature processing on the main storage device using the private key. If the secret key is stored in the smart device, the hash value is input into the smart device, the signature is generated in the smart device, and the signature value is acquired.
  • the new transaction generation unit 1071 generates a new transaction including the recording information acquired in step S5010, the signature generated in step S5040, the public template certificate, and the public key certificate (S5050).
  • the data structure of the new transaction will be described later with reference to FIG.
  • FIG. 6 is a flowchart showing a processing procedure of transaction verification (S4250). This process is performed only when the verification terminal 1100 receives a new transaction, verifies the validity of the public template certificate, public key certificate, and signature value included in the new transaction, and succeeds in all verifications. The new transaction is verified successfully.
  • S4250 transaction verification
  • the verification terminal 1100 verifies the validity of the public template certificate included in the new transaction (S6010).
  • the public template certificate is given the signature value generated with the private key of the certificate authority in step S2130.
  • the signature value is verified using the public key of the certificate authority. Thereby, the verification terminal 1100 can verify that the public template certificate is surely issued by the certificate authority.
  • the verification terminal 1100 proceeds to the next step S6030 if the verification result of the public template certificate is successful, and substitutes the failure for the transaction verification result if it is unsuccessful (S6051).
  • the verification terminal 1100 verifies the validity of the public key certificate included in the new transaction using the public template certificate included in the existing transaction (S6030).
  • the public key certificate is given a biometric signature using biometric information as a key.
  • the validity of the biometric signature is verified by using the public template certificate to confirm whether or not the biometric signature is surely given by the principal.
  • the verification terminal 1100 can verify that the user who generated the public template certificate included in the existing transaction is the same as the user who generated the public key certificate included in the new transaction.
  • the user who generated the public template certificate included in the existing transaction corresponds to the currency destination in the case of virtual currency
  • the user who generated the public key certificate included in the new transaction corresponds to the currency source in the case of virtual currency. Correspond.
  • step S6030 it is verified that the public key certificate is not included in the certificate revocation list.
  • the certificate revocation list is a mechanism for invalidating a public key certificate corresponding to a private key and causing signature verification to fail due to loss, theft, or other reasons of the private key.
  • the certificate revocation list issuance procedure is shown in FIG. 7, and the data structure of the certificate revocation list is shown later in FIG. 9D.
  • the verification terminal 1100 compares the serial number included in the public template certificate with the public template serial number included in the certificate revocation list, and then the public key certificate and the public included in the certificate revocation list. The key serial number is compared, and if the two match, the validity of the biometric signature value (9364) is verified using the public template, and further the validity of the signature value (9370) of the certificate revocation list is verified. To do. If all the verifications are successful, the verification terminal 1100 determines that the public key certificate has expired and determines that the verification has failed.
  • the verification terminal 1100 performs conditional branching based on the verification result of step S6030 (S6040). If the verification is successful, the process proceeds to the processing after step S6050. If the verification fails, the transaction verification result is failed. Substitute (S6051).
  • the hash value generation unit 1161 of the verification terminal 1100 generates a hash value from the data in the new transaction (S6050).
  • the signature verification unit 1140 of the verification terminal 1100 verifies the validity of the signature using the hash value and public key certificate generated in step S6050 (S6060). Since the signature terminal 1000 is generated by the signing terminal 1000 using the secret key for the hash value of the new transaction in step S5040, the verification terminal 1100 verifies the validity with the public key corresponding to the secret key. be able to.
  • the verification terminal 1100 verifies that the user having the secret key has generated a new transaction, and further verifies that the content of the new transaction has not been tampered with later.
  • the verification terminal 1100 performs conditional branching based on the verification result in step S6060 (S6070). If the verification succeeds, success is substituted for the transaction verification result (S6080). If the verification fails, the transaction verification result Failure is substituted for (S6051). The verification terminal 1100 can notify the signature terminal 1000 of the transaction verification result.
  • the verification terminal 1100 completes the process of verifying the contents of the transaction.
  • Figures 2 to 6 show the flow from initial registration of a public template certificate, generation of a new transaction, and verification of the transaction.
  • An object of the present invention is to make it possible to use a block chain system safely and continuously even when a user's private key is lost or stolen. Therefore, in addition to the normal processing procedure of FIGS. 2 to 6, when the private key is lost or stolen, the public key certificate corresponding to the private key is revoked and a new public key certificate is issued.
  • FIG. 7 is a flowchart showing a processing procedure for revoking a public key certificate. Hereinafter, the procedure will be described with reference to the drawings.
  • the signing terminal 1000 acquires the public template certificate of the user who revokes the public key certificate (S7010). This process corresponds to the case where the signature terminal 1000 reads the data when the public template certificate is stored in the public template certificate storage unit 1092 of the signature terminal 1000.
  • the signing terminal 1000 uses the public template repository 1200 based on the serial number. To obtain a public template certificate.
  • the signing terminal 1000 acquires the revoked public key certificate from the key storage unit 1091 (S7020).
  • the public key revocation application generation unit 1080 of the signing terminal 1000 generates a public key revocation application using the public template certificate acquired in step S7010 and the public key certificate acquired in step S7020 (S7030).
  • the data structure of the public key revocation application will be described later with reference to FIG. 9C.
  • the signing terminal 1000 transmits the public key revocation application generated in step S7030 to the public template repository 1200 (S7040).
  • the signing terminal 1000 also transmits the public key revocation application to the user terminal 1300 that transmits and receives transactions.
  • the public template repository 1200 and the user terminal 1300 can verify that the current public key certificate of the signing terminal 1000 has expired.
  • the public template repository 1200 receives the public key revocation application (S7110), and the public key revocation application verification unit 1230 verifies the public key revocation application (S7120). In this verification, the public key revocation application verification unit 1230 verifies using the public template certificate that the signature value assigned to the public key revocation application is correct.
  • the public key revocation application verification unit 1230 acquires a public template certificate corresponding to the user using the public template serial number included in the public key revocation application. Further, the public key revocation application verification unit 1230 verifies the validity of the signature value included in the public key revocation application using the public template certificate.
  • the public key revocation application verification unit 1230 performs conditional branching based on the verification result of step S7120 (S7130). If the verification is successful, the certificate revocation list generation unit 1240 generates a certificate revocation list 9300, and the certificate It is stored in the revocation list storage unit 1291 (S7140). The data structure of the certificate revocation list will be described later with reference to FIG. 9D.
  • the certificate revocation list issued by the public template repository 1200 is used for verification in the public key certificate verification in step S6030 of FIG. 6, and if the public key certificate exists in the certificate revocation list, the verification fails. .
  • the transaction verification in step S4220 shown in FIG. 4 fails and the transaction is not approved.
  • a third party obtains a secret key, it is impossible to impersonate the transaction by impersonating it.
  • FIG. 8 is a flowchart showing a processing procedure for reissuing a public key certificate according to the first embodiment of the present invention.
  • a new public key certificate that is newly used by the signing terminal 1000 is generated.
  • the public key certificate shown in FIG. 7 is not revoked, it may be automatically revoked when the public key certificate expires.
  • the public key certificate shown in FIG. 8 can be reissued without revoking the public key certificate shown in FIG.
  • the public key certificate shown in FIG. 8 can be reissued when the public key certificate has not expired. This is performed when a plurality of different public key certificates are issued and private keys corresponding to the public key are stored in a plurality of terminals of the same user, or when loaned to different users.
  • FIG. 8 is a flowchart showing a processing procedure for reissuing a public key certificate according to the first embodiment of the present invention.
  • the signing terminal 1000 acquires a public template certificate (S8010).
  • the signature terminal 1000 acquires a public template certificate from the public template certificate storage unit 1092 or the public template repository 1200.
  • the signing terminal 1000 acquires the user's biometric information (S8020).
  • the biometric information acquisition unit 1020 acquires biometric information such as the user's fingerprint, vein, and face image by the biometric sensor.
  • the signing terminal 1000 verifies the validity of the biometric information acquired in step S8020 using the public template certificate acquired in step S8010 (S8030). In the verification, the signature terminal 1000 uses the biometric signature to determine whether the biometric information based on the generation of the public template certificate and the biometric information acquired in step S8020 are acquired from the same person. Verification is made when the same person is verified, and when the person is different, the verification is failed.
  • the signing terminal 1000 performs conditional branching based on the verification result in step S8030 (S8040). If successful, the signature terminal 1000 performs the processing from step S8050 onwards, and if unsuccessful, assigns “issue failure” to the reissue result (S8051). The reissue result is displayed on the output device of the signature terminal 1000 (S8090).
  • step S8040 the key pair generation unit 1040 of the signing terminal 1000 generates a new key pair of a new secret key and a new public key (S8050). This process is generated based on publicly known or well-known public key cryptography as in S3030.
  • the public key certificate generation unit 1050 of the signing terminal 1000 generates a new public key certificate based on the new public key generated in step S8050 (S8060).
  • the signature terminal 1000 gives a biometric signature using the biometric information acquired in step S8020 as a key to the new public key.
  • the signing terminal 1000 stores the new private key and the new public key certificate generated in step S8050 in the key storage unit 1091 (S8070). In addition, the signing terminal 1000 transmits the new public key certificate to the user terminal 1300 that transmits and receives transactions.
  • the signing terminal 1000 substitutes “issue success” for the reissue result of the public key certificate (S8080), and displays the reissue result on the signing terminal 1000 (S8090).
  • the transaction generated using this new private key can be verified with the new public key certificate. Therefore, in the first embodiment, even when the secret key is lost or leaked, it is possible to issue a new secret key and continuously use the block chain system.
  • the public key certificate generation unit 1050 of the signing terminal 1000 acquires the public template certificate of the user who reissues the key pair from the public template certificate storage unit 1092 after generating the public key revocation application. . If the biometric information of the user is acquired and the public template 9080 and the biometric information included in the public template certificate are successfully verified, the user can block by reissuing the key pair and the public key certificate. Use of the chain system can be continued.
  • 9A to 9D are diagrams showing the data structures of the public template certificate, public key certificate, public key revocation application, certificate revocation list.
  • FIG. 9A is a diagram showing an example of a public template certificate 9000.
  • the public template certificate 9000 is data generated in step S2130 of FIG.
  • the basic data structure is obtained by adding other header information to the public template 9080 and adding a signature value 9091.
  • the public key certificate standard in the PKI (Public Key Infrastructure) is X. 509. Hereinafter, each data will be described.
  • Version 9010 indicates the version of the public template certificate as a character string.
  • the public template serial number 9020 is a character string uniquely assigned to the public template by the public template repository 1200 and is assigned so as not to overlap.
  • the signature algorithm 9030 indicates an algorithm for generating a signature value (9091) to be assigned to the public template certificate.
  • Issuer 9040 indicates an entity that issues a public template certificate, that is, a certificate authority.
  • the expiration date 9050 indicates the date and time of the expiration date of the public template certificate.
  • the subject 9060 indicates the subject of the public template certificate, that is, the user who requests issuance.
  • the biometric signature algorithm 9070 indicates an algorithm for generating a public template 9080.
  • the public template 9080 indicates the public template generated in step S3020 of FIG.
  • the signature algorithm 9090 indicates an algorithm for generating a signature value (9091) to be assigned to the public template certificate, like the signature algorithm 9030.
  • the signature value 9091 is a value obtained by inputting data from 9010 to 9080 into a hash function (for example, SHA1, SHA256, etc.) and converting the obtained hash value with the private key of the certificate authority.
  • a hash function for example, SHA1, SHA256, etc.
  • FIG. 9B is a diagram showing an example of the data structure of the public key certificate.
  • the public key certificate 9100 is data in which a biometric signature with biometric information as a key is added to the public key generated in step S3040 or S8060, and is a public key certificate standard in PKI (Public Key Infrastructure). X. 509.
  • PKI Public Key Infrastructure
  • Version 9110 indicates a character string indicating the version of the public template certificate.
  • the public template serial number 9120 is a serial number that is uniquely assigned to the public template by the public template repository 1200 and is assigned so as not to overlap.
  • the public key serial number 9121 is a unique character string given to the public key by the key pair generation unit 1040 of the signing terminal 1000, and is generated so as not to overlap with different public keys.
  • the biometric signature algorithm 9130 indicates an algorithm for generating a biometric signature value 9191.
  • the issuer 9140 indicates an entity that issues a public template certificate, that is, a certificate authority.
  • the expiration date 9150 indicates the date and time of the expiration date of the public template certificate.
  • the subject 9160 indicates the subject of the public template certificate, that is, the user who requests issuance.
  • the public key algorithm 9170 indicates an algorithm for generating the public key 9180.
  • the public key 9180 indicates the public key generated in steps S3030 and S8050.
  • the biometric signature algorithm 9190 indicates an algorithm for generating a biometric signature value 9191, similar to the above 9130.
  • the biometric signature value 9191 is obtained by inputting the data 9110 to 9180 to a hash function (for example, SHA1, SHA256, etc.) and generating a biometric signature using biometric information as a key for the obtained hash value. This is the value obtained.
  • a hash function for example, SHA1, SHA256, etc.
  • FIG. 9C is a diagram showing an example of the data structure of the public key revocation application.
  • the public key revocation application form 9200 is generated in step S7030 by the public key revocation application generation unit 1080 of the signing terminal 1000.
  • the public template serial number 9210, the public key serial number 9220, and the revocation date 9230 Data with a biometric signature using biometric information as a key.
  • the public template serial number 9210 and the public key serial number 9220 are data copied from the public template serial number 9120 and the public key serial number 9121 of the public key certificate 9100, respectively.
  • the public template serial number 9210 and the public key serial number 9220 are used as identifiers for specifying the public key certificate 9100.
  • the revocation date 9230 describes the date when the public key certificate is revoked. After this date, verification using the public key certificate fails.
  • the biometric signature value 9240 inputs the data of 9210 to 9230 to a hash function (for example, SHA1, SHA256, etc.), acquires the hash value, and generates a biometric signature using the biometric information as a key for the hash value. Can be obtained.
  • a hash function for example, SHA1, SHA256, etc.
  • FIG. 9D is a diagram showing an example of the data structure of the certificate revocation list.
  • the certificate revocation list 9300 is generated in step S7140 in the public template repository 1200, and includes data including one or more public key revocation applications, and a header and a signature value. This will be described below with reference to the drawings.
  • Version 9310 indicates a character string indicating the version of the certificate revocation list.
  • the signature algorithm 9320 indicates a signature algorithm used for generating a signature value 9380 given to the certificate revocation list.
  • Issuer 9330 indicates a character string indicating the subject issuing the certificate revocation list.
  • This update date and time 9340 indicates the date and time when the target certificate revocation list is issued.
  • the next update date and time 9350 indicates the date and time when the certificate revocation list is issued next.
  • 9361-9364 corresponds to 9210-9240 of the public key revocation application form.
  • public key revocation applications accepted during a certain period are collected and included in the certificate revocation list.
  • the signature algorithm 9370 indicates a signature algorithm used to generate a signature value 9380 for the certificate revocation list, as in the above 9320.
  • the signature value 9380 is obtained by inputting the data of 9310 to 9364 into a hash function (for example, SHA1, SHA256, etc.), and adding the signature with the private key of the certificate authority held by the public template repository 1200 to the obtained hash value. Is.
  • a hash function for example, SHA1, SHA256, etc.
  • the above is the data structure of the certificate revocation list.
  • FIG. 10 is a diagram illustrating a data structure of a block chain targeted by the first embodiment.
  • FIG. 10 includes an existing transaction 10010 and a new transaction 10110.
  • the existing transaction 10010 is a transaction received in step S4010, and a new transaction 10110 is a transaction generated in step S5050.
  • a new transaction 10110 is a transaction generated in step S5050.
  • the existing transaction 10010 is a transaction in which transaction information from the user A to the user B is recorded.
  • the public key certificate 10020 of the user A (transaction source), a public template certificate 10030 of the user B (transaction partner), and recording information 10040, generation date / time 10050, hash value 10060, and user A signature 10070.
  • user A corresponds to a remittance source and user B corresponds to a remittance destination.
  • User A's public key certificate 10020 is the public key certificate generated in step S3040 or step S8060.
  • the public key certificate may be stored in the above-mentioned 10020 as it is. However, data obtained by converting the public key certificate according to some regularity may be entered and restored when the public key certificate is used. Further, only the serial number of the public key certificate may be stored in 10020, and when using the public key certificate, the public key certificate may be acquired using the serial number.
  • User B's public template certificate 10030 is the public template certificate generated in step S2130.
  • the public template certificate may store converted data and a serial number as in the public key certificate 10020 of the user A.
  • the record information 10040 is an object whose contents are guaranteed by the block chain system, and includes, for example, remittance in the case of virtual currency and contract contents in the case of smart contract.
  • the generation date / time 10050 indicates the date / time when the existing transaction 10010 was generated.
  • the hash value 10060 is a hash value obtained by inputting the entire transaction before the existing transaction to the hash function.
  • the signature 10070 of the user A is obtained by inputting the contents (10020 to 10050) of the existing transaction and the hash value 10060 into the hash function to calculate a total hash value, and signing the total hash value with the secret key of the user A Is generated.
  • the new transaction 10110 is a transaction generated after the existing transaction 10010 and indicates a transaction from the user B to the user C.
  • User B's public key certificate 10120, user C's public template certificate 10130, recording information 10140, generation date / time 10150, hash value 10160 of the previous transaction, and user B's signature included in the new transaction 10110 10170 is the same as the public key certificate 10020 of user A, public template certificate 10030 of user B, recording information 10040, generation date and time 10050, hash value 10060, and signature 10070 of user A in the existing transaction 10010, respectively.
  • the new transaction 10110 is generated in step S5050 and then verified in step S4220.
  • the verification terminal 1100 first verifies the validity of the public template certificate 10130 of the user C using the public key of the certificate authority, and then uses the public template certificate 10030 of the user B to check the user B's public template certificate 10030.
  • the validity of the public key certificate 10120 is verified, and then the validity of the user B signature 10170 is verified using the user B public key certificate 10120.
  • the verification terminal 1100 approves the transaction.
  • user B's public key is stored in an existing transaction
  • user B's signature is stored in a new transaction, and then verified. For this reason, when the user B loses his / her private key after the existing transaction is generated, the new transaction cannot be signed and the transaction cannot be generated continuously.
  • the public template certificate 10030 of the user B is stored in the existing transaction 10010
  • the public key certificate 10120 of the user B and the signature 10170 of the user B are stored in the new transaction 10110, and then verified.
  • the verification of the validity of the transaction in the first embodiment is composed of two stages such as a public template certificate and a public key certificate, and a public key certificate and a signature.
  • the user B can reissue the public key certificate by using the biometric information of the user B as a key even when the private key is lost. Since the biometric information is a feature in the user B's body, it is not easily lost or leaked like a normal secret key.
  • FIG. 11 is a block diagram showing a hardware configuration of the signature terminal 1000, the public template repository 1200, and the verification terminal 1100 in the block chain system.
  • reference numeral 10 is a CPU (Central Processing Unit)
  • reference numeral 20 is a main storage device
  • reference numeral 30 is an auxiliary storage device
  • reference numeral 40 is an input device
  • reference numeral 50 is an output device
  • reference numeral 60 is a communication device.
  • the CPU 10 includes a public template generation unit 1030, a key pair generation unit 1040, a public key certificate generation unit 1050, a hash value generation unit 1061, a signature generation unit 1070, a new transaction generation unit 1071, a public key revocation application generation unit 1080, a disclosure.
  • Programs corresponding to the key certificate verification unit 1120, the signature verification unit 1140, the public template certificate generation unit 1220, the public key revocation application verification unit 1230, and the certificate revocation list generation unit 1240 are executed.
  • the main storage device 20 is a device equivalent to a computer memory, and includes a public template generation unit 1030, a key pair generation unit 1040, a public key certificate generation unit 1050, a hash value generation unit 1061, a signature generation unit 1070, and a new transaction generation.
  • the auxiliary storage device 30 is a storage device represented by an HDD (Hard Disk Drive), an SSD (Solid State Drive), and the like, and includes a key storage unit 1091, a public template certificate storage unit 1092, a public template certificate storage unit 1290, This corresponds to the certificate revocation list storage unit 1291. Data stored by each unit is accumulated as data on the auxiliary storage device 11030.
  • HDD Hard Disk Drive
  • SSD Solid State Drive
  • the input device 40 includes a sensor and a mouse keyboard.
  • the output device 50 includes a display that outputs information on the main storage device 11020.
  • the communication device 60 is used when the signature terminal 1000, the public template repository 1200, and the verification terminal 1100 communicate with the network 100.
  • the CPU 10 operates as a functional unit that provides a predetermined function by processing according to the program of each functional unit.
  • the CPU 10 functions as the public template generation unit 1030 by performing processing according to the public template generation program. The same applies to other programs.
  • the CPU 10 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are an apparatus and a system including these functional units.
  • auxiliary storage device 30 nonvolatile semiconductor memory, hard disk drive, SSD (Solid State Drive), or a computer such as an IC card, SD card, DVD, etc. Can be stored on any non-transitory data storage medium.
  • a public template certificate is generated from a user's biometric information, a pair of a private key and a public key is generated, and a biometric signature is assigned to the public key using the user's biometric information as a key.
  • Generate a public key certificate add a signature to the message using the private key when generating the user's signature, verify the validity of the public key certificate with the public template certificate and verify the signature The validity of the user's signature is verified using the key certificate, and when the key is updated, a private key / public key pair is generated again. It can be issued.
  • the transaction includes a public key certificate of the business partner and a public template certificate of the business partner, and at the time of signature verification, a new (second) is used by using the public template certificate 10030 of the existing (first) transaction 10010. ) Verifying the validity of the public key certificate 10120 of the transaction 10110, and then verifying the validity of the user signature 10170 included in the new transaction 10110 using the public key certificate 10120 included in the new transaction 10110.
  • a blockchain system can be constructed.
  • the signing terminal 1000 revokes the private key and reissues a new private key, and the block chain system is continuously used.
  • a system that can be used is configured without using the public template repository 1200.
  • the public template repository 1200 is set as a trusted third party, and a public template certificate and a certificate revocation list are issued via the public template repository 1200.
  • Such a blockchain system was able to issue highly reliable public template certificates and certificate revocation lists by the public template repository 1200 functioning as a certificate authority.
  • blockchain systems are also desired to manage transactions at low cost without having a reliable third-party organization.
  • blockchain systems System operating costs increase.
  • FIG. 12 is a block diagram illustrating an example of a block chain system according to the second embodiment.
  • the public template certificate generation unit that was operating in the public template repository 1200 of the first embodiment is operated on the signing terminal 1000, and the public key revocation application form 9200 is retained on the signing terminal 1000. Is different from the first embodiment.
  • FIG. 13 is a flowchart illustrating an example of an initial registration process for a public template certificate according to the second embodiment.
  • the process of the public template repository 1200 is deleted from the process of FIG. 2 of the first embodiment, and the signature terminal 1000 executes a public template certificate generation process.
  • step S2010 the signing terminal 1000 performs initial registration as in the first embodiment.
  • the public template certificate generation unit 1090 generates a public template certificate in step S2035.
  • the public template certificate generation unit 1090 adds a signature to the public template and generates a public template certificate.
  • step S2040 the public template certificate generation unit 1090 registers the public template certificate in the public template certificate storage unit 1092.
  • FIG. 15 is a diagram illustrating an example of the public template certificate 9000 according to the second embodiment.
  • the public template certificate 9000 of the second embodiment is obtained by deleting the public template serial number 9020 of FIG. 9A of the first embodiment.
  • the issuer 9040 stores the identifier of the signing terminal 1000 in place of the certificate authority of the first embodiment as a subject that issues a public template certificate.
  • the signature value 9091 of the public template certificate is a biometric signature that uses the user's biometric information (public template) as a key, instead of the signature of the certificate authority. In this way, it is possible to detect tampering by a third party by assigning a self-signed biometric signature to the public template certificate.
  • the signature value 9091 is verified using the public key of the certificate authority in the public template certificate verification S6010.
  • the signature value 9091 is verified using the public template 9080. This verifies that the public template certificate has not been tampered with.
  • the processes after S6020 in the second embodiment are the same as those in the first embodiment.
  • FIG. 14 is a flowchart illustrating an example of processing for revoking the public key certificate of the second embodiment.
  • the validity of the public key revocation application form is verified in the public template repository 1200 (S7120), and the certificate revocation list is issued when the verification is successful (S7140).
  • the signing terminal 1000 since the public template repository 1200 has been deleted, the signing terminal 1000 generates a public key revocation application in step S7050.
  • the verification terminal 1100 stores the generated public key revocation application and uses it when verifying the transaction.
  • FIG. 16 is a diagram illustrating a public key certificate 9100 according to the second embodiment.
  • the public template serial number 9120 of the public key certificate 9100 shown in FIG. 9B of the first embodiment is not included in the public template certificate. Instead, the public template 9120A itself or the public template 9080 is included in the public template 9120A. Stores the hash value of. Other configurations are the same as those of the first embodiment.
  • FIG. 17 is a diagram showing a public key revocation application form 9200 of the second embodiment.
  • the public template serial number 9210 of the public key revocation application form 9200 shown in FIG. 9C of the first embodiment is not included in the public revocation application form. Instead, the public template 9080 itself or the public template 9080 is disclosed in the public template 9210A. Stores the hash value of the template. Other configurations are the same as those of the first embodiment.
  • the certificate revocation list 9300 shown in FIG. 9D of the first embodiment is not issued.
  • the second embodiment realizes a block chain system that can be continuously used even when the private key is lost or leaked without using the public template repository 1200.
  • the validity of each certificate can be determined based on the user's biometric information even in a blockchain system that does not use a certificate authority.
  • the cost required for the certificate authority can be reduced.
  • the third embodiment shows a block chain system in which a registration terminal for generating biometric information and generating a key pair and a public template is added to the block chain system of the first embodiment.
  • FIG. 18 is a block diagram illustrating a block chain system according to the third embodiment.
  • the block chain system includes a registration terminal 1400 for registering keys of users A to C and a public template certificate, a verification terminal 1100 for verifying the validity of a transaction, a public template repository 1200 for generating a public template certificate, a transaction Are connected via the network 100.
  • the verification terminal 1100 and the public template repository 1200 are the same as those in the first embodiment.
  • User terminals 1300-A to 1300-C are the same as the signature terminal 1000 of the first embodiment, and the entire user terminal is denoted by reference numeral 1300.
  • the registration terminal 1400 is obtained by omitting a functional unit for generating a transaction from the signature terminal 1000 of the first embodiment, and includes a recording information acquisition unit 1060, a signature generation unit 1070, a hash value generation unit 1061, and the like shown in FIG.
  • the new transaction generation unit 1071 is omitted.
  • Other configurations are the same as those of the first embodiment.
  • the users A to C of the block chain system first acquire biometric information with the registration terminal 1400 and register the public template certificate and the key.
  • the respective keys and certificates are transmitted from the registration terminal 1400 to the user terminals 1300-A to 1300-C used by the users A to C and stored.
  • each user transmits / receives a public key and the like before transmitting a transaction.
  • the key pair and certificate may be transmitted offline.
  • the public key certificate may be generated by the user terminal 1300.
  • FIG. 19 is a sequence diagram illustrating an example of a registration process performed in the block chain system. This process is the same as FIG. 2 and FIG. 3 of the first embodiment, and is a registration process performed by the user for the first time using the block chain system. Below, an example of the registration process of the user A is shown.
  • the biometric information acquisition unit 1020 acquires the biometric information of the user A (S301).
  • the public template generation unit 1030 generates a public template by performing unidirectional conversion on the biological information acquired in step S301 (S302).
  • the public template generation unit 1030 transmits the generated public template to the public template repository 1200 (S303).
  • the key pair generation unit 1040 of the registration terminal 1400 generates a private key / public key pair (S304).
  • the public key certificate generation unit 1050 of the registration terminal 1400 generates a public key certificate by adding a biometric signature using the biometric information acquired in step S301 as a key to the generated public key (S305). .
  • the registration terminal 1400 stores the private key, public key, and public key certificate in the key storage unit 1091 (S306).
  • the public template certificate generation unit 1220 generates a public template certificate by adding a signature to the received public template (S309).
  • the signature is signed using the private key of the certificate authority.
  • the public template repository 1200 registers the generated public template certificate in the public template certificate storage unit 1290 (S310), and further transmits the public template certificate to the registration terminal 1400 (S311). Upon receiving the public template certificate, the registration terminal 1400 registers it in the public template certificate storage unit 1092 (S307).
  • the registration terminal 1400 transmits the key pair, the public key certificate, and the public template certificate to the user terminal 1300-A used by the user A (S308).
  • the user terminal 1300-A registers the received key pair and public key certificate in the key storage unit 1091 and registers the public template certificate in the public template certificate storage unit 1092 (S312).
  • the user terminal 1300-A transmits the public key and the public template to the user terminal 1300-B that transmits the transaction (S313).
  • the user terminal 1300-A registers the received public key and public template in the storage (S314).
  • the key pair and public key certificate are generated, the registration process is completed, and the preparation for sending and receiving the transaction is completed.
  • FIG. 20 is a sequence diagram illustrating an example of a transaction verification process performed in the blockchain system. This process is the same as in FIGS. 4 to 6 of the first embodiment.
  • the user A receives the existing transaction transmitted by the user B, and the user A generates a new transaction and sends it to the user C. An example of performing verification at the time of transmission is shown.
  • the user terminal 1300-B transmits an existing transaction, and the user terminal 1300-A receives it (S401).
  • Transaction transmission is broadcast within the blockchain system, and a public key or public template is transmitted using a P2P network.
  • the user terminal 1300-A adds the signature of the user A to the existing transaction, generates a new transaction (S402), and broadcasts the user terminal 1300-C as the destination (S403).
  • the verification terminal 1100 receives the broadcasted new transaction and starts verification.
  • the verification terminal 1100 verifies the validity of the public template certificate included in the new transaction (S404).
  • the public template certificate is given a signature value generated with the private key of the certificate authority, and the verification terminal 1100 verifies the validity of the signature value using the public key of the certificate authority. Thereby, the verification terminal 1100 can verify that the public template certificate is surely issued by the certificate authority.
  • the verification terminal 1100 verifies the validity of the public key certificate included in the new transaction using the public template certificate included in the existing transaction (S405).
  • the public key certificate has a biometric signature with biometric information as a key.
  • the validity of the biometric signature is verified by using the public template certificate to confirm whether or not the biometric signature is surely given by the principal.
  • the verification terminal 1100 can verify that the user who generated the public template certificate included in the existing transaction is the same as the user who generated the public key certificate included in the new transaction. In step S405, it is verified that the public key certificate is not included in the certificate revocation list 9300.
  • the verification terminal 1100 verifies the validity of the signature (S406). This processing is the same as steps S6050 to 6070 in FIG. 6 shown in the first embodiment, and the verification terminal 1100 generates a hash value and uses the generated hash value and public key certificate to verify the validity of the signature. Verify sex.
  • the verification terminal 1100 notifies the user terminals 1300-A and 1300-C of the public template certificate, the public key certificate, and the signature verification result.
  • the verification terminal 1100 can verify the contents of the transaction.
  • FIG. 21 is a sequence diagram showing an example of a key reissue process performed in the block chain system. This process is the same as in FIGS. 7 and 8 of the first embodiment, and FIG. 21 shows an example in which the user A has lost the secret key.
  • the registration terminal 1400 Since the user A of the user terminal 1300-A has lost the secret key (S501), the registration terminal 1400 starts a key reissue process.
  • the registration terminal 1400 obtains the public key certificate and public template certificate of the user A from the key storage unit 1091 and the public template certificate storage unit 1092 to generate a public key revocation application (S502), and the public template repository 1200. (S503).
  • the public template repository 1200 verifies the validity of the public key revocation application (S503). In this verification, the public template repository 1200 verifies that the signature value assigned to the public key revocation application is correct using the public template certificate. If the verification is successful, the public template repository 1200 issues a public key revocation list (S504). The public template repository 1200 registers the public key revocation list in the certificate revocation list storage unit 1291 and transmits it to the registration terminal 1400.
  • the registration terminal 1400 acquires the biometric information of the user A after receiving the public key revocation list (S505).
  • the registration terminal 1400 uses the biometric signature of the public template certificate to verify whether the biometric information based on the generation of the public template certificate and the acquired biometric information are obtained from the same person. In the case of the same person, the verification is successful.
  • the registration terminal 1400 If the verification is successful, the registration terminal 1400 generates a key pair in the same manner as in the first embodiment (S507), adds a signature to the public key, and generates a public key certificate (S508).
  • the registration terminal 1400 registers the key pair and public key certificate in the key storage unit 1091 (S509), and then transmits the key pair and public key certificate to the user terminal 1300-A of the user A (S510).
  • the user terminal 1300-A deletes the old key pair and public key certificate, and registers the received new key pair and public key certificate in the key storage unit 1091 (S511). Next, the user terminal 1300-A transmits the public key to the user terminal 1300-B that transmits and receives transactions (S512).
  • the user terminal 1300-B deletes the old public key of the user A and registers the newly received public key in the key storage unit 1091 (S513).
  • the public key certificate can be reissued by giving a signature to the public key using the biometric information of the user acquired using the registration terminal 1400 as a key.
  • the registration terminal 1400 in an organization that manages the blockchain system and acquire biometric information after the blockchain system administrator or the like confirms the identity of the user. . Thereby, the registration by the person's impersonation can be suppressed.
  • the registration terminal 1400 and the public template repository 1200 can be configured by a single computer.
  • the registration unit public key certificate generation unit 1450, public template certificate generation unit 1220, public key revocation application form generation unit 1080
  • the registration terminal 1400, the public template repository 1200, and the verification terminal 1100 may be configured by a single computer.
  • the registration unit and the verification unit public key certificate verification unit 1120 can be provided by one computer.
  • the fourth embodiment is obtained by changing a part of the transaction of the block chain system of the first embodiment or the third embodiment, and the other configuration is the same as the first embodiment or the third embodiment.
  • FIG. 22 is a block diagram illustrating an example of a data structure of a block chain according to the fourth embodiment.
  • public template serial numbers (S / N) 10031 and 10131 are used instead of the public template certificates 10030 and 10130. This is a change.
  • the public template serial number 10031 (10131) can be assigned as a value associated with the public template certificate when the public template certificate of the public template repository 1200 is generated. Alternatively, when a public template is generated by the registration terminal 1400, it can be given as a value associated with the public template.
  • the public template serial number 10031 (10131) may be an identifier unique within the block chain system.
  • the public template repository 1200 stores the public template certificate and the public template serial number in the public template certificate storage unit 1290 in association with each other.
  • the verification terminal 1100 may request the public template repository 1200 for the public template certificate corresponding to the public template serial number 10031 (10131).
  • the size of the transaction is suppressed by setting the public template serial number 10031 (10131) as an identifier for identifying the user instead of the public template certificate in the transaction.
  • the verification terminal 1100 can acquire the public template serial number 10031 and search the public template repository 1200 for acquisition.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • each of the above-described configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function.
  • Information such as programs, tables, and files for realizing each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.
  • control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

ユーザの生体情報を取得する生体情報取得部と、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、を備える署名端末と、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証する公開鍵証明書検証部と、前記公開鍵証明書で前記署名を検証する署名検証部と、を備える検証端末と、を有する署名検証システム。

Description

署名検証システム、署名検証方法及び記憶媒体 参照による取り込み
　本出願は、平成２８年（２０１６年）７月２１日に出願された日本出願である特願２０１６－１４３１５２の優先権を主張し、その内容を参照することにより、本出願に取り込む。
　本発明は、Ｐ２Ｐ（Peer-to-peer）ネットワーク上で分散型台帳管理を実現するブロックチェーン（署名検証）システムに関する。
　Ｐ２Ｐネットワーク上で分散型台帳管理を実現する技術として、ブロックチェーンがある。ブロックチェーンでは、記録情報を含むトランザクションを作成し、それを電子署名に基づき鎖状に繋ぐことで、記録情報の一貫性を確保している。
　ブロックチェーンの一例として、非特許文献１で開示されたＢｉｔｃｏｉｎに代表される、記録情報を保証するユーザが自らの秘密鍵でトランザクションに対して電子署名を付与することでチェーンを形成するシステムがある。このようなブロックチェーンシステムでは、トランザクション内に含まれる公開鍵に基づき、トランザクションに対する電子署名を検証することで、正規のユーザがトランザクションを生成したことを判定する。
特開２０１３－１２３１４２号公報
ＮＡＫＡＭＯＴＯ, Ｓａｔｏｓｈｉ　著、"Bitcoin: A peer-to-peer electronic cash system." 、２００８年発行
　ブロックチェーンシステムでは、ユーザが自らの秘密鍵を用いて電子署名を生成することでトランザクションを生成するため、当該秘密鍵を紛失した場合、正しいトランザクションを生成することができなくなり、継続的にシステムを利用することが困難となる。また、秘密鍵の盗難に遭った場合は、秘密鍵を取得した第三者が不正にトランザクションを生成することが可能となり、なりすましを行うことが可能となる。
　このような課題に対する自明かつ有効な解として、紛失や盗難が起きにくい形で秘密情報を管理する方式が挙げられる。紛失や盗難が起きにくい情報に基づき公開鍵暗号を実現する方式として、特許文献１で開示されている生体署名がある。生体署名は、指紋、静脈、顔などに代表される生体情報を鍵として、メッセージに対する署名生成や署名検証を実現する技術である。生体情報は人間の身体的な特徴をセンシングしたものであるため、公知または周知の公開鍵暗号の秘密鍵に比べて、紛失や盗難が発生しにくい。
　しかしながら、ブロックチェーンシステムのユースケースによっては、頻繁にトランザクションの生成を行う必要がある場合や、人が介在せず自動的にトランザクション生成を行う必要がある場合がある。このような場合は、トランザクション生成の度にユーザの電子署名を必要とする。生体署名ではトランザクション生成の度に生体情報を入力することになるので、ユーザの利便性が低下する可能性があった。
　本発明の目的は、秘密鍵の紛失や漏洩が発生した場合にも、継続的なトランザクション生成を可能とするシステムを、ユーザの利便性を低下させずに実現することである。
　本発明は、プロセッサとメモリを備えた計算機で署名を検証する署名検証システムであって、ユーザの生体情報を取得する生体情報取得部と、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する検証部と、を有する。
　本発明によれば、ユーザの既存秘密鍵の紛失または漏洩が発生した際には、ユーザが公開鍵失効申請書を発行することで、既存の秘密鍵を用いたトランザクション生成を無効化し、新たな秘密鍵と新たな公開鍵のペアを生成し、生体情報を鍵として新たな公開鍵に生体署名を付与することで新たな公開鍵証明書を発行し、その後、新たな秘密鍵を用いてトランザクションの生成を行うことで、既存の秘密鍵を使わずに継続的に署名検証システムを利用することが可能になる。
本発明の実施例１を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例１を示し、公開テンプレート証明書発行の処理手順を示すフローチャートである。 本発明の実施例１を示し、初期登録の処理手順を示すフローチャートである。 本発明の実施例１を示し、ブロックチェーンシステムにおけるトランザクション生成及びトランザクション検証の処理手順を示すフローチャートである。 本発明の実施例１を示し、新トランザクション生成の処理手順を示すフローチャートである。 本発明の実施例１を示し、トランザクション検証の処理手順を示すフローチャートである。 本発明の実施例１を示し、公開鍵失効の処理手順を示すフローチャートである。 本発明の実施例１を示し、鍵再発行の処理手順を示すフローチャートである。 本発明の実施例１を示し、公開テンプレート証明書のデータ構造を示す図である。 本発明の実施例１を示し、公開鍵証明書のデータ構造を示す図である。 本発明の実施例１を示し、公開鍵失効申請書のデータ構造を示す図である。 本発明の実施例１を示し、証明書失効リストのデータ構造を示す図である。 本発明の実施例１を示し、生体署名を活用したブロックチェーンのデータ構造を示す図である。 本発明の実施例１を示し、署名端末、検証端末、公開テンプレートリポジトリのハードウェア構成を示すブロック図である。 本発明の実施例２を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例２を示し、公開テンプレート証明書発行の処理手順を示すフローチャートである。 本発明の実施例２を示し、公開鍵失効の処理手順を示すフローチャートである。 本発明の実施例２を示し、公開テンプレート証明書のデータ構造を示す図である。 本発明の実施例２を示し、公開鍵証明書のデータ構造を示す図である。 本発明の実施例２を示し、公開鍵失効申請書のデータ構造を示す図である。 本発明の実施例３を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われる登録処理の一例を示すシーケンス図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われるトランザクションの検証処理の一例を示すシーケンス図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われる鍵の再発行処理の一例を示すシーケンス図である。 本発明の実施例４を示し、生体署名を活用したブロックチェーンのデータ構造を示す図である。
　以下、本発明の実施形態を添付図面に基づいて説明する。
　本実施例は、ブロックチェーンシステム（生体署名システム）のユーザが自らの秘密鍵の紛失または漏洩時に、ユーザの生体情報を鍵とする生体署名を用いることで、秘密鍵を失効（無効化）させて新たな秘密鍵を再発行し、継続的にブロックチェーンシステムを利用することを可能とするシステムである。
　以降、図面を参照して手順を説明する。
　図１は、本発明の実施例１の、ブロックチェーンシステムの構成の一例を示すブロック図である。ブロックチェーンシステムは、署名端末１０００と、検証端末１１０００と、公開テンプレートリポジトリ１２００と、ユーザ端末１３００と、これらの端末を相互に接続するネットワーク１００、を含む。
　この図において、署名端末１０００は、通信部１０１０と、生体情報取得部１０２０と、公開テンプレート生成部１０３０と、鍵ペア生成部１０４０と、公開鍵証明書生成部１０５０と、記録情報取得部１０６０と、ハッシュ値生成部１０６１と、署名生成部１０７０と、新トランザクション生成部１０７１と、公開鍵失効申請書生成部１０８０、鍵格納部１０９１、公開テンプレート証明書格納部１０９２を含んで構成される。
　通信部１０１０は、ネットワーク１００を介して検証端末１１００と、公開テンプレートリポジトリ１２００の間で通信を行う。
　生体情報取得部１０２０は、例えば、指紋センサ、静脈センサ、カメラなどを介して、ユーザから指紋、静脈、顔画像などの生体情報を取得する。なお、生体情報を取得するセンサとして携帯電話やスマートフォンの指紋センサや静脈センサやカメラを用いることができる。
　公開テンプレート生成部１０３０は、特許文献１の方式に従い、生体情報取得部１０２０で取得した生体情報に対して一方向性（不可逆）変換を施すことで、公開テンプレートを生成する。なお、一方向性変換としては、公知または周知の変換処理を適用すれば良い。
　鍵ペア生成部１０４０は、公知または周知の公開鍵暗号（ＲＳＡ、ＤＳＡ、など）を用いて、秘密鍵と公開鍵のペアを生成する。
　公開鍵証明書生成部１０５０は、鍵ペア生成部１０４０で生成された公開鍵に対して、生体情報取得部１０２０で取得した生体情報を鍵とする生体署名を付与することで公開鍵証明書を生成する。
　記録情報取得部１０６０は、トランザクション内に書き込む記録情報を入力装置からの入力などから取得する。
　ハッシュ値生成部１０６１は、記録情報取得部１０６０で取得した記録情報やその他の情報を所定のハッシュ関数へ入力することで、ハッシュ値を生成する。
　署名生成部１０７０は、ハッシュ値生成部１０６１で生成されたハッシュ値に対して、秘密鍵を用いて署名値を生成する。
　新トランザクション生成部は、公開鍵証明書生成部１０５０で生成された公開鍵証明書と、公開テンプレート証明書（後述）と、記録情報取得部１０６０で取得した記録情報と、ハッシュ値生成部１０６１で生成されたハッシュ値と、署名生成部１０７０で生成された署名などを含む新トランザクションを生成する。
　公開鍵失効申請書生成部１０８０は、公開鍵証明書生成部１０５０で生成された公開鍵証明書から公開鍵失効申請書を生成する。
　次に、検証端末１１００は、通信部１１１０と、公開鍵証明書検証部１１２０と、ハッシュ値生成部１１６１と、署名検証部１１４０を含んで構成される。
　公開鍵証明書検証部１１２０は、署名端末１０００の公開鍵証明書生成部１０５０で生成された公開鍵証明書を公開テンプレートを用いて正当性を検証する。
　署名検証部１１４０は、署名端末１０００の署名生成部１０７０で生成された署名値を公開鍵証明書を用いて正当性を検証する。
　通信部１１１０は、ネットワーク１００を介して署名端末１０００と、公開テンプレートリポジトリ１２００の間で通信を行う。
　次に、公開テンプレートリポジトリ１２００は、通信部１２１０と、公開テンプレート証明書生成部１２２０と、公開鍵失効申請書検証部１２３０と、証明書失効リスト生成部１２４０と、公開テンプレート証明書格納部１２９０と、証明書失効リスト格納部１２９１を含んで構成される。
　公開テンプレート証明書生成部１２２０は、署名端末１０００の公開テンプレート生成部１０３０で生成された公開テンプレートから公開テンプレート証明書を生成する。
　公開鍵失効申請書検証部１２３０は、署名端末１０００の公開鍵失効申請書生成部１０８０で生成された公開鍵失効申請書を、公開テンプレート証明書生成部１２２０で生成された公開テンプレート証明書で正当性を検証する。
　証明書失効リスト生成部１２４０は、署名端末１０００の公開鍵失効申請書生成部１０８０で生成された公開鍵失効申請書に基づき、証明書失効リスト９３００（図９Ｄ）を生成する。
　公開テンプレート証明書格納部１２９０は、公開テンプレート証明書生成部１２２０で生成された公開テンプレート証明書を格納する。
　証明書失効リスト格納部１２９１は、証明書失効リスト生成部１２４０で生成された証明書失効リスト９３００を格納する。通信部１２１０は、ネットワーク１００を介して署名端末１０００と、検証端末１１００との間で通信を行う。
　ユーザ端末１３００は、ユーザＢが利用する計算機で、署名端末１０００を利用するユーザＡがトランザクションを送信する送信先となる。ユーザ端末１３００は、署名端末１０００と同様の構成の計算機である。
　本発明の実施例１の処理手順を、図２～図１１を参照しながら説明する。
　図２は、本発明の実施例１の、公開テンプレート証明書の初期登録の処理手順を示したフローチャートである。本処理は、署名端末１０００がユーザから生体情報を取得し、公開テンプレートリポジトリ１２００が公開テンプレート証明書を生成することで、その後ブロックチェーンシステムを利用可能とする処理である。以降、各手順を説明する。
　署名端末１０００にて、初期登録を行う（Ｓ２０１０）。初期登録の具体的な手順は、図３を参照して後ほど説明する。この手順により、公開テンプレートを生成する。
　署名端末１０００は、公開テンプレートを公開テンプレートリポジトリ１２００へ送信する（Ｓ２０２０）。この際、署名端末１０００は、ユーザ名や、公開テンプレートを生成するために用いた生体署名アルゴリズムなど、公開テンプレート証明書を生成するために必要となる情報も同時に送信する。なお、改ざん防止のため、それらの情報に対して生体署名を付与しても良い。
　公開テンプレートリポジトリ１２００は、公開テンプレートを受信し（Ｓ２１１０）、受信した公開テンプレートに対するシリアル番号を発行する（Ｓ２１２０）。シリアル番号は公開テンプレートに対して一意に付与される番号であり、重複しないように公開テンプレートリポジトリ１２００にて管理される。
　公開テンプレートリポジトリ１２００は、公開テンプレートに対して署名を付与し、公開テンプレート証明書を生成して登録する（Ｓ２１３０）。公開テンプレート証明書のデータ構造は、図９Ａを参照して後ほど説明する。本実施例１では、公開テンプレートリポジトリ１２００が信頼できる第三者機関として機能しており、不正は行われないことを仮定する。
　このため、公開テンプレートに対する署名は、公開テンプレートリポジトリ１２００が保管する認証局の秘密鍵を用いて生成される。これにより、公開テンプレート証明書は認証局の秘密鍵を持たない第三者には生成困難となり、不正な公開テンプレート証明書が発行されてなりすましなどが発生することを防止することが可能となる。
　公開テンプレートリポジトリ１２００は、ステップＳ２１３０で生成された公開テンプレート証明書を署名端末１０００に送信し（Ｓ２１４０）、署名端末１０００は公開テンプレート証明書を受信する（Ｓ２０３０）。
　署名端末１０００は、ステップＳ２０３０で受信した公開テンプレート証明書を、公開テンプレート証明書格納部１０９２に格納する（Ｓ２０４０）。
　以上により、公開テンプレート証明書の初期登録が完了する。
　次に、図２のステップＳ２０１０で行われる初期登録処理の具体的な手順を、図３を参照して説明する。
　署名端末１０００の生体情報取得部１０２０にて、ユーザの生体情報を取得する（Ｓ３０１０）。署名端末１０００には、指紋センサ、静脈センサ、カメラなどの生体センサが接続されており、これらのセンサを使って、生体情報取得部１０２０はユーザの指紋、静脈、顔画像などの生体情報を取得する。
　公開テンプレート生成部１０３０は、ステップＳ３０１０で取得した生体情報に対して一方向性変換を施すことで、公開テンプレートを生成する（Ｓ３０２０）。この変換には、生体情報に含まれる誤差を補正して、一意のデータを生成し、得られたデータを鍵として暗号処理を行う、バイオメトリック暗号方式を採用する。この変換として用いることができる方式としては、例えばＦｕｚｚｙ　Ｃｏｍｍｉｔｍｅｎｔ、Ｆｕｚｚｙ　Ｖａｕｌｔや、特許文献１に開示されている生体署名などがある。以降では、特許文献１に開示されている生体署名を前提として説明する。
　生体署名では、生体情報に対して一方向性変換を施すことで公開テンプレートを生成する。公開テンプレートを第三者が取得しても生体情報を復元することは非常に困難であり、公開鍵と同様に公開情報として扱うことができる。
　署名端末１０００の鍵ペア生成部１０４０は、秘密鍵と公開鍵の鍵ペアを生成する（Ｓ３０３０）。この鍵ペアは、公知または周知のＲＳＡ暗号、ＤＳＡ暗号、Ｅｌｇａｍａｌ暗号などの公開鍵暗号に基づき生成される。
　署名端末１０００の公開鍵証明書生成部１０５０は、ステップＳ３０３０で得られた公開鍵に対して、ステップＳ３０１０で取得した生体情報を鍵とする生体署名を付与することで、公開鍵証明書を生成する（Ｓ３０４０）。公開鍵証明書のデータ構造については、図９Ｂを参照して後ほど説明する。
　署名端末１０００は、ステップＳ３０３０で生成した秘密鍵およびステップＳ３０４０で生成した公開鍵証明書を鍵格納部１０９１に格納する（Ｓ３０５０）。
　以上により、鍵ペアと公開鍵証明書が生成されてステップＳ２０１０の初期登録処理が完了する。
　図４は、図２に示す初期登録が完了した後実施される、ブロックチェーンシステムにおけるトランザクション生成と検証の手順を示した図である。本処理では、署名端末１０００において初期登録を終えた後、既存トランザクションに対して新たなトランザクションを生成し、検証端末１１００において新たなトランザクションの正当性を検証する。以降、図を参照して手順を説明する。
　署名端末１０００にて、既存トランザクションを受信する（Ｓ４０１０）。既存トランザクションは、ブロックチェーンシステムにおいて過去に生成されたトランザクションであり、これから生成する新トランザクションの１つ前に位置するものである。
　例えば、ブロックチェーンを使った仮想通貨の場合、既存トランザクションは他人から自分への送金を示すトランザクションであり、新トランザクションはその送金された仮想通貨を他人へ送金するトランザクションとなる。
　既存トランザクションと新トランザクションのデータ構造については、図１０を参照して後ほど説明する。また、既存トランザクションはネットワーク（Ｐ２Ｐネットワーク）１００から通信部１０１０を介して取得する。なお、事前に既存トランザクションを収集しておき、署名端末１０００における記録装置から読み込むことで既存トランザクションを取得しても良い。
　署名端末１０００は、ステップＳ４０１０で受信した既存トランザクションの次に繋がるトランザクションとして、新トランザクションを生成する（Ｓ４０１１）。新トランザクション生成の詳細な手順については、図５を参照して後ほど説明する。
　署名端末１０００は、ステップＳ４０１０で受信した既存トランザクションとＳ４０１１で生成した新トランザクションを、通信部１０１０を用いて検証端末１１００へ送信する（Ｓ４０３０）。
　検証端末１１００は、ステップＳ４０３０で送信された既存トランザクションと新トランザクションを、通信部１１１０を用いて受信する（Ｓ４２１０）。なお、図４では簡略化のため署名端末１０００と検証端末１１００が直接通信を行って必要なデータをやり取りしているが、実際のブロックチェーンシステムでは、署名端末１０００及び検証端末１１００は多数の端末が接続されたネットワーク１００に接続されており、データは他の端末を経由して送受信される。
　検証端末１１００は、当該既存トランザクション内に含まれる公開テンプレート証明書を用いてトランザクションの正当性の検証を行う（Ｓ４２２０）。トランザクションの検証では、既存トランザクションと新トランザクションの内容に不整合が存在せず、かつ確かに正規のユーザが生成したものであることを判定する。トランザクション検証の詳細な手順は、図６を参照して後ほど説明する。
　検証端末１１００は、トランザクションの検証結果によって条件分岐を行い（Ｓ４２３０）、当該検証結果が成功のときのみ新トランザクションを承認する（Ｓ４２４０）。トランザクションの承認は、検証端末１１００が当該新トランザクションは適切なものであることを認める処理であり、具体的な手順は対象とするブロックチェーンシステムにより異なる。例えば、ブロックチェーンを用いた仮想通貨の一つであるビットコインの場合は、承認した新トランザクションをまとめた上で、ヘッダを追加してブロックを生成する。
　以上により、ブロックチェーンシステムにおけるトランザクション生成と検証が完了する。
　図５は、本発明の実施例１の、新トランザクション生成（Ｓ４０２０）の処理手順を示すフローチャートである。以降、図を参照して手順を説明する。
　署名端末１０００は、新トランザクションに含める記録情報（メッセージ）を取得する（Ｓ５０１０）。記録情報は、ブロックチェーンシステムの中で承認を得る対象の情報であり、例えば仮想通貨の場合はユーザ間の通貨の取引であり、スマートコントラクトの場合は契約内容となる。
　署名端末１０００のハッシュ値生成部１０６１は、新トランザクションに含まれる情報のハッシュ値を生成する（Ｓ５０２０）。
　次に、署名端末１０００の新トランザクション生成部１０７１は、署名を付与するため、鍵格納部１０９１に格納されている秘密鍵を活性化させる（Ｓ５０３０）。秘密鍵の活性化は、鍵格納部１０９１が署名端末１０００内の補助記憶装置であれば、当該補助記憶装置から主記憶装置へ秘密鍵データを読み出すことで行われる。その際、秘密鍵がパスワードで暗号化されている場合は、ユーザからパスワードを受け付け、復号した上で秘密鍵を取り出す。また、秘密鍵がＩＣカードなどのスマートデバイスの中に格納されている場合は、パスワードをスマートデバイスへ入力することで秘密鍵を活性化させる。
　署名端末１０００の署名生成部１０７０は、ステップＳ５０２０で生成したハッシュ値に対して、ステップＳ５０３０で活性化した秘密鍵を用いて署名を付与する（Ｓ５０４０）。署名生成部１０７０は、ステップＳ５０３０で活性化した秘密鍵が署名端末１０００の主記憶装置に格納された場合は、当該秘密鍵を用いて主記憶装置上で署名処理を行う。なお、秘密鍵がスマートデバイス内に格納されている場合は、ハッシュ値をスマートデバイス内に入力した上で、スマートデバイス内で署名生成を行い、その署名値を取得する。
　新トランザクション生成部１０７１は、ステップＳ５０１０で取得した記録情報と、ステップＳ５０４０で生成した署名と、公開テンプレート証明書と公開鍵証明書を含む新トランザクションを生成する（Ｓ５０５０）。新トランザクションのデータ構造は、図１０を参照して後ほど説明する。
　以上の手順により、新トランザクションの生成が完了する。
　図６は、トランザクション検証（Ｓ４２５０）の処理手順を示すフローチャートである。本処理は、検証端末１１００が新トランザクションを受け付けて、当該新トランザクションに含まれる公開テンプレート証明書と、公開鍵証明書と、署名値の正当性をそれぞれ検証し、全ての検証に成功したときのみ、新トランザクションの検証成功とする。以降、図を参照して説明する。
　検証端末１１００は、新トランザクションに含まれる公開テンプレート証明書の正当性を検証する（Ｓ６０１０）。公開テンプレート証明書には、ステップＳ２１３０で認証局の秘密鍵で生成した署名値が付与されており、本手順では当該署名値を認証局の公開鍵を用いて検証する。これにより、検証端末１１００は、公開テンプレート証明書が確かに認証局によって発行されたものであることを検証できる。
　検証端末１１００は、公開テンプレート証明書の検証結果が成功であれば次のステップＳ６０３０に進み、失敗であればトランザクション検証結果に失敗を代入する（Ｓ６０５１）。
　検証端末１１００は、新トランザクションに含まれる公開鍵証明書を、既存トランザクションに含まれる公開テンプレート証明書を用いて正当性を検証する（Ｓ６０３０）。公開鍵証明書にはステップＳ３０４０にて生体情報を鍵とする生体署名が付与されている。この生体署名が、確かに本人が付与したものか否かを、公開テンプレート証明書を用いて正当性を検証する。
　これにより、検証端末１１００は、既存トランザクションに含まれる公開テンプレート証明書を生成したユーザと、新トランザクションに含まれる公開鍵証明書を生成したユーザが同一であることが検証できる。既存トランザクションに含まれる公開テンプレート証明書を生成したユーザは、仮想通貨の場合通貨の送り先に対応し、新トランザクションに含まれる公開鍵証明書を生成したユーザは、仮想通貨の場合通貨の送り元に対応する。
　すなわち、仮想通貨の場合、この検証は、送金したいユーザが確かに過去に送金を受けて通貨を保有していることを示している。さらに、ステップＳ６０３０では、公開鍵証明書が証明書失効リストに含まれていないことを検証する。
　証明書失効リストは、秘密鍵の紛失、盗難、その他の事由で、秘密鍵に対応する公開鍵証明書を無効にし、署名検証に失敗するようにするための仕組みである。証明書失効リストの発行手順は図７、証明書失効リストのデータ構造は図９Ｄにて、後ほど示す。
　具体的には、検証端末１１００が、公開テンプレート証明書に含まれるシリアル番号と証明書失効リストに含まれる公開テンプレートシリアル番号とを比較し、その後公開鍵証明書と証明書失効リストに含まれる公開鍵シリアル番号とを比較し、両者が一致していれば公開テンプレートを用いて生体署名値（９３６４）の正当性の検証を行い、さらに証明書失効リストの署名値（９３７０）の正当性を検証する。検証端末１１００は、全ての検証に成功した場合、公開鍵証明書が失効していると判定し、検証失敗とする。
　検証端末１１００は、ステップＳ６０３０の検証結果に基づき条件分岐を行い（Ｓ６０４０）、当該検証に成功した場合は、ステップＳ６０５０以降の処理に進み、当該検証に失敗した場合は、トランザクション検証結果に失敗を代入する（Ｓ６０５１）。
　検証端末１１００のハッシュ値生成部１１６１は、新トランザクション内のデータからハッシュ値を生成する（Ｓ６０５０）。
　検証端末１１００の署名検証部１１４０は、ステップＳ６０５０で生成したハッシュ値と公開鍵証明書を用いて、署名の正当性を検証する（Ｓ６０６０）。署名は、署名端末１０００がステップＳ５０４０にて新トランザクションのハッシュ値に対して秘密鍵を用いて生成したものであるため、検証端末１１００では秘密鍵に対応する公開鍵にて正当性の検証を行うことができる。
　検証端末１１００は、当該検証にて、秘密鍵を持つユーザが新トランザクションを生成したことを検証し、さらに、新トランザクションの内容に後から改ざんが加えられていないことを検証する。
　検証端末１１００は、ステップＳ６０６０の検証結果に基づき条件分岐を行い（Ｓ６０７０）、当該検証に成功した場合は、トランザクション検証結果に成功を代入し（Ｓ６０８０）、当該検証に失敗した場合はトランザクション検証結果に失敗を代入する（Ｓ６０５１）。検証端末１１００は、トランザクション検証結果を署名端末１０００に通知することができる。
　以上により、検証端末１１００は、トランザクションの内容を検証する処理が完了する。
　図２～図６では、公開テンプレート証明書の初期登録を行い、新トランザクションを生成し、当該トランザクションを検証するまでの流れを示した。本発明は、ユーザの秘密鍵の紛失や盗難時にも、安全かつ継続的にブロックチェーンシステムを利用できるようにすることを目的としている。このため、図２～図６の通常の処理手順に加えて、秘密鍵の紛失または盗難時に、秘密鍵に対応する公開鍵証明書の失効や新たな公開鍵証明書の発行を行う。
　図７は、公開鍵証明書を失効させる際の処理手順を示したフローチャートである。以降、図を参照して手順を説明する。
　署名端末１０００は、公開鍵証明書を失効させるユーザの公開テンプレート証明書を取得する（Ｓ７０１０）。この処理は、署名端末１０００の公開テンプレート証明書格納部１０９２に公開テンプレート証明書が格納されている場合は、署名端末１０００が、そのデータを読み出すことに相当する。また、公開テンプレート証明書のシリアル番号を入力された場合、または公開テンプレート証明書のシリアル番号のみを補助記憶装置に格納していた場合は、署名端末１０００が、当該シリアル番号に基づき公開テンプレートリポジトリ１２００へ問い合わせを行い、公開テンプレート証明書を取得する。
　失効する公開鍵証明書を署名端末１０００が鍵格納部１０９１から取得する（Ｓ７０２０）。
　署名端末１０００の公開鍵失効申請書生成部１０８０は、ステップＳ７０１０で取得した公開テンプレート証明書およびステップＳ７０２０で取得した公開鍵証明書を用いて、公開鍵失効申請書を生成する（Ｓ７０３０）。公開鍵失効申請書のデータ構造は、図９Ｃを用いて後ほど説明する。
　署名端末１０００は、ステップＳ７０３０で生成した公開鍵失効申請書を公開テンプレートリポジトリ１２００へ送信する（Ｓ７０４０）。また、署名端末１０００は、トランザクションの送受信を行うユーザ端末１３００にも公開鍵失効申請書を送信しておく。これにより、公開テンプレートリポジトリ１２００やユーザ端末１３００は、署名端末１０００の現在の公開鍵証明書が失効したことを検証することができる。
　公開テンプレートリポジトリ１２００は、公開鍵失効申請書を受信し（Ｓ７１１０）、公開鍵失効申請書検証部１２３０が当該公開鍵失効申請書を検証する（Ｓ７１２０）。この検証では、公開鍵失効申請書検証部１２３０が公開鍵失効申請書に付与された署名値が正しいことを、公開テンプレート証明書を用いて検証する。
　具体的には、公開鍵失効申請書検証部１２３０が公開鍵失効申請書に含まれる公開テンプレートシリアル番号を用いてユーザに対応する公開テンプレート証明書を取得する。さらに、公開鍵失効申請書検証部１２３０は、当該公開テンプレート証明書を用いて、公開鍵失効申請書に含まれる署名値の正当性を検証する。
　公開鍵失効申請書検証部１２３０は、ステップＳ７１２０の検証結果に基づき条件分岐を行い（Ｓ７１３０）、検証に成功した場合には証明書失効リスト生成部１２４０が証明書失効リスト９３００を生成し、証明書失効リスト格納部１２９１に格納する（Ｓ７１４０）。証明書失効リストのデータ構造は、図９Ｄを参照して後ほど説明する。
　以上により、公開鍵証明書の失効が完了する。公開テンプレートリポジトリ１２００が発行した証明書失効リストは、図６のステップＳ６０３０の公開鍵証明書検証にて検証に用いられ、公開鍵証明書が証明書失効リストに存在する場合は、検証に失敗する。これにより、秘密鍵の紛失、盗難、その他の理由で公開鍵証明書を失効させると、図４に示したステップＳ４２２０のトランザクション検証に失敗するため、トランザクションが承認されなくなる。これにより、第三者が秘密鍵を取得した場合でも、なりすましを行って不正にトランザクションを承認させることができなくなる。
　図８は、本発明の実施例１の、公開鍵証明書を再発行する際の処理手順を示したフローチャートである。本処理では、図７で示した公開鍵証明書の失効（公開鍵失効申請書の生成）を行った後、署名端末１０００が新たに用いる新たな公開鍵証明書を生成する。なお、図７で示した公開鍵証明書の失効を行わなくても、公開鍵証明書の有効期限を迎えることで自動的に失効する場合もある。このような場合は、図７で示した公開鍵証明書の失効を行わずに、図８に示した公開鍵証明書の再発行を行うこともできる。また、公開鍵証明書が失効していない時点で図８に示した公開鍵証明書の再発行を行うこともできる。これは、異なる複数の公開鍵証明書を発行して、公開鍵に対応する秘密鍵を同一ユーザの複数の端末に格納する場合や、異なるユーザへ貸与する場合に行う。以降、図８を参照して説明する。
　署名端末１０００は、公開テンプレート証明書を取得する（Ｓ８０１０）。この処理では、図７のステップＳ７０１０と同様に、署名端末１０００が公開テンプレート証明書格納部１０９２、または公開テンプレートリポジトリ１２００から公開テンプレート証明書を取得する。
　署名端末１０００は、ユーザの生体情報を取得する（Ｓ８０２０）。この処理では、図３のステップＳ３０１０と同様に、生体情報取得部１０２０が生体センサによりユーザの指紋、静脈、顔画像などの生体情報を取得する。
　署名端末１０００は、ステップＳ８０１０で取得した公開テンプレート証明書を用いて、ステップＳ８０２０で取得した生体情報の正当性を検証する（Ｓ８０３０）。当該検証では、署名端末１０００が、生体署名を用いて、公開テンプレート証明書を生成した際に元にした生体情報と、ステップＳ８０２０で取得した生体情報とが同一人物から取得したものであるかを検証し、同一人物の場合は検証成功とし、異なる人物の場合は検証失敗とする。
　署名端末１０００は、ステップＳ８０３０の検証結果に基づき条件分岐を行い（Ｓ８０４０）、成功した場合はステップＳ８０５０以降の処理を行い、失敗した場合は再発行結果に「発行失敗」を代入し（Ｓ８０５１）、当該再発行結果を署名端末１０００の出力装置に表示する（Ｓ８０９０）。
　ステップＳ８０４０の検証に成功した場合、署名端末１０００の鍵ペア生成部１０４０は、新秘密鍵と新公開鍵の新鍵ペアを生成する（Ｓ８０５０）。この処理はＳ３０３０と同様に、公知または周知の公開鍵暗号に基づき生成される。
　署名端末１０００の公開鍵証明書生成部１０５０は、ステップＳ８０５０で生成した新公開鍵に基づき、新公開鍵証明書を生成する（Ｓ８０６０）。この処理では、図３のステップＳ３０４０と同様に、署名端末１０００が新公開鍵に対してステップＳ８０２０で取得した生体情報を鍵とする生体署名を付与する。
　署名端末１０００は、ステップＳ８０５０で生成した新秘密鍵及び新公開鍵証明書を、鍵格納部１０９１に格納する（Ｓ８０７０）。また、署名端末１０００は、トランザクションの送受信を行うユーザ端末１３００に新公開鍵証明書を送信しておく。
　署名端末１０００は、公開鍵証明書の再発行結果に「発行成功」を代入し（Ｓ８０８０）、再発行結果を署名端末１０００に表示する（Ｓ８０９０）。
　以上により、公開鍵証明書の再発行（更新）が完了する。この処理により、署名端末１０００の鍵格納部１０９１内の秘密鍵及び公開鍵証明書がアップデートされ、以降の署名生成及び署名検証では新秘密鍵と新公開鍵証明書が用いられる。
　この新秘密鍵を用いて生成したトランザクションは、新公開鍵証明書で正当性を検証することができる。このため、本実施例１では秘密鍵の紛失や漏洩時にも、新たに秘密鍵を発行して継続的にブロックチェーンシステムを利用することが可能となる。
　上記処理により、署名端末１０００の公開鍵証明書生成部１０５０は、公開鍵失効申請書を生成した後に、鍵ペアを再発行するユーザの公開テンプレート証明書を公開テンプレート証明書格納部１０９２から取得する。そして、当該ユーザの生体情報を取得して、公開テンプレート証明書に含まれる公開テンプレート９０８０と生体情報の検証に成功すれば、鍵ペアと公開鍵証明書を再発行することで、当該ユーザはブロックチェーンシステムの利用を継続することができる。
　図９Ａ～図９Ｄは、公開テンプレート証明書、公開鍵証明書、公開鍵失効申請書、証明書失効リスト、それぞれのデータ構造を示した図である。
　図９Ａは、公開テンプレート証明書９０００の一例を示す図である。公開テンプレート証明書９０００は、図２のステップＳ２１３０で生成されるデータである。基本的なデータ構造は、公開テンプレート９０８０に対してその他のヘッダ情報を付与して、署名値９０９１を付与したものであり、ＰＫＩ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における公開鍵証明書の規格であるＸ．５０９に準拠している。以降、それぞれのデータについて説明する。
　バージョン９０１０は公開テンプレート証明書のバージョンを文字列で示す。
　公開テンプレートシリアル番号９０２０は、公開テンプレートリポジトリ１２００が公開テンプレートに対して一意に割り振る文字列であり、重複しないように付与される。
　署名アルゴリズム９０３０は、公開テンプレート証明書に対して付与する署名値（９０９１）を生成するアルゴリズムを示す。
　発行者９０４０は、公開テンプレート証明書を発行する主体、つまり認証局を示す。
　有効期限９０５０は、公開テンプレート証明書の有効期限の日時を示す。
　サブジェクト９０６０は、公開テンプレート証明書の主体者、つまり発行を依頼するユーザを示している。
　生体署名アルゴリズム９０７０は、公開テンプレート９０８０を生成するアルゴリズムを示す。
　公開テンプレート９０８０は、図３のステップＳ３０２０にて生成された公開テンプレートを示す。
　署名アルゴリズム９０９０は、署名アルゴリズム９０３０と同じく、公開テンプレート証明書に対して付与する署名値（９０９１）を生成するアルゴリズムを示す。
　署名値９０９１は、９０１０～９０８０までのデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、得られたハッシュ値を認証局の秘密鍵で変換して得られる値である。
　以上が公開テンプレート証明書のデータ構造である。
　図９Ｂは、公開鍵証明書のデータ構造の一例を示す図である。
　公開鍵証明書９１００は、ステップＳ３０４０またはＳ８０６０で生成する、公開鍵に対して生体情報を鍵とする生体署名を付与したデータであり、ＰＫＩ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における公開鍵証明書の規格であるＸ．５０９に準拠している。以降、図を参照して説明する。
　バージョン９１１０は公開テンプレート証明書のバージョンを表す文字列を示す。
　公開テンプレートシリアル番号９１２０は、公開テンプレートリポジトリ１２００が公開テンプレートに対して一意に割り振るシリアル番号であり、重複しないように付与される。
　公開鍵シリアル番号９１２１は、公開鍵に対して署名端末１０００の鍵ペア生成部１０４０が付与する一意の文字列であり、異なる公開鍵で重複しないように生成される。
　生体署名アルゴリズム９１３０は、生体署名値９１９１を生成するアルゴリズムを示す。
　発行者９１４０は、公開テンプレート証明書を発行する主体、つまり認証局を示す。
　有効期限９１５０は、公開テンプレート証明書の有効期限の日時を示す。
　サブジェクト９１６０は、公開テンプレート証明書の主体者、つまり発行を依頼するユーザを示している。
　公開鍵アルゴリズム９１７０は、公開鍵９１８０を生成するアルゴリズムを示す。
　公開鍵９１８０は、ステップＳ３０３０やＳ８０５０で生成する公開鍵を示す。
　生体署名アルゴリズム９１９０は、上記９１３０と同じく、生体署名値９１９１を生成するアルゴリズムを示す。
　生体署名値９１９１は、上記９１１０～９１８０までのデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、得られたハッシュ値に対して、生体情報を鍵とする生体署名を生成することで得られる値である。
　以上が公開鍵証明書のデータ構造である。
　図９Ｃは、公開鍵失効申請書のデータ構造の一例を示す図である。
　公開鍵失効申請書９２００は、署名端末１０００の公開鍵失効申請書生成部１０８０にてステップＳ７０３０で生成されるものであり、公開テンプレートシリアル番号９２１０、公開鍵シリアル番号９２２０、失効日時９２３０に対して、生体情報を鍵とする生体署名を付与したデータである。
　公開テンプレートシリアル番号９２１０、公開鍵シリアル番号９２２０は、それぞれ公開鍵証明書９１００の公開テンプレートシリアル番号９１２０と、公開鍵シリアル番号９１２１からコピーしたデータである。なお、公開テンプレートシリアル番号９２１０及び公開鍵シリアル番号９２２０は、公開鍵証明書９１００を特定する識別子として使用する。
　失効日時９２３０は、公開鍵証明書を失効させる日時を記載しており、この日時以降、公開鍵証明書を用いた検証には失敗するようになる。
　生体署名値９２４０は、上記９２１０～９２３０のデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、ハッシュ値を取得し、当該ハッシュ値に対して生体情報を鍵とする生体署名を生成することで得られる。
　以上が公開鍵失効申請書のデータ構造である。
　図９Ｄは、証明書失効リストのデータ構造の一例を示す図である。
　証明書失効リスト９３００は、公開テンプレートリポジトリ１２００にてステップＳ７１４０で生成されるものであり、公開鍵失効申請書を１つまたは複数含み、ヘッダ及び署名値を付与したデータである。以降で図を参照して説明する。
　バージョン９３１０は、証明書失効リストのバージョンを表す文字列を示す。
　署名アルゴリズム９３２０は、証明書失効リストに対して付与される署名値９３８０の生成に用いる署名アルゴリズムを示す。
　発行者９３３０は、証明書失効リストを発行する主体を示す文字列を示す。
　今回の更新日時９３４０は、対象の証明書失効リストを発行した日時を示す。
　次回の更新日時９３５０は、次に証明書失効リストが発行される日時を示す。
　９３６１～９３６４は、公開鍵失効申請書の９２１０～９２４０に対応する。証明書失効リストでは、一定期間に受理した公開鍵失効申請書をまとめて、証明書失効リストに含める。
　署名アルゴリズム９３７０は、上記９３２０と同様に、証明書失効リストに対する署名値９３８０を生成するために用いる署名アルゴリズムを示す。
　署名値９３８０は、９３１０～９３６４のデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）に入力し、得られたハッシュ値に対して公開テンプレートリポジトリ１２００が保持する認証局の秘密鍵で署名を付与したものである。
　以上が、証明書失効リストのデータ構造である。
　図１０は、本実施例１が対象とするブロックチェーンのデータ構造を示した図である。図１０には既存トランザクション１００１０及び新トランザクション１０１１０が含まれる。
　既存トランザクション１００１０は、ステップＳ４０１０にて受信するトランザクションであり、新トランザクション１０１１０は、ステップＳ５０５０にて生成するトランザクションである。以降、図を参照して各データについて説明する。
　既存トランザクション１００１０は、ユーザＡからユーザＢに対する取引情報を記録したトランザクションであり、ユーザＡ（取引元）の公開鍵証明書１００２０と、ユーザＢ（取引先）の公開テンプレート証明書１００３０と、記録情報１００４０と、生成日時１００５０と、ハッシュ値１００６０と、ユーザＡの署名１００７０を含んで構成される。例えば、ブロックチェーンに基づく仮想通貨の場合、ユーザＡは送金元、ユーザＢは送金先に相当する。
　ユーザＡの公開鍵証明書１００２０は、ステップＳ３０４０またはステップＳ８０６０で生成される公開鍵証明書である。なお、上記１００２０には公開鍵証明書をそのまま格納しても良いが、公開鍵証明書を何らかの規則性に従って変換したデータを入れ、公開鍵証明書を使うときに復元しても良い。また、１００２０に公開鍵証明書のシリアル番号のみを格納し、公開鍵証明書を使うときにはシリアル番号を使って公開鍵証明書を取得しても良い。
　ユーザＢの公開テンプレート証明書１００３０は、ステップＳ２１３０で生成される公開テンプレート証明書である。なお、当該公開テンプレート証明書は、ユーザＡの公開鍵証明書１００２０と同様に、変換したデータやシリアル番号を格納しても良い。
　記録情報１００４０は、ブロックチェーンシステムにより内容を保証する対象であり、例えば仮想通貨の場合は送金額、スマートコントラクトの場合は契約内容などが含まれる。
　生成日時１００５０は、既存トランザクション１００１０を生成した日時を示す。
　ハッシュ値１００６０は、既存トランザクションの前のトランザクション全体をハッシュ関数へ入力することで得られるハッシュ値である。
　ユーザＡの署名１００７０は、既存トランザクションの内容（１００２０～１００５０）と、ハッシュ値１００６０をハッシュ関数に入力して総合ハッシュ値を算出し、当該総合ハッシュ値に対して、ユーザＡの秘密鍵で署名を生成したものである。
　新トランザクション１０１１０は、既存トランザクション１００１０の次に生成したトランザクションであり、ユーザＢからユーザＣへの取引を示す。
　新トランザクション１０１１０に含まれる、ユーザＢの公開鍵証明書１０１２０と、ユーザＣの公開テンプレート証明書１０１３０と、記録情報１０１４０と、生成日時１０１５０と、前のトランザクションのハッシュ値１０１６０と、ユーザＢの署名１０１７０は、それぞれ既存トランザクション１００１０におけるユーザＡの公開鍵証明書１００２０、ユーザＢの公開テンプレート証明書１００３０、記録情報１００４０、生成日時１００５０、ハッシュ値１００６０、ユーザＡの署名１００７０と同様である。
　新トランザクション１０１１０は、ステップＳ５０５０で生成された後、ステップＳ４２２０で検証される。新トランザクション検証時には、まず、検証端末１１００は、ユーザＣの公開テンプレート証明書１０１３０を認証局の公開鍵を用いて正当性を検証し、その後ユーザＢの公開テンプレート証明書１００３０を用いてユーザＢの公開鍵証明書１０１２０の正当性を検証し、その後ユーザＢの公開鍵証明書１０１２０を用いてユーザＢの署名１０１７０の正当性を検証する。この全ての検証に成功したとき、検証端末１１００はトランザクションを承認する。
　公知のブロックチェーンシステムでは、既存トランザクションにユーザＢの公開鍵を格納し、新トランザクションにユーザＢの署名を格納した上で、それらを検証する。このため、既存トランザクションが生成された後、ユーザＢが自らの秘密鍵を紛失した場合、新トランザクションに署名を打つことができず、継続的にトランザクションを生成することができなかった。
　本実施例１では、既存トランザクション１００１０にユーザＢの公開テンプレート証明書１００３０を格納し、新トランザクション１０１１０にユーザＢの公開鍵証明書１０１２０とユーザＢの署名１０１７０を格納した上で、それらを検証する。本実施例１におけるトランザクションの正当性の検証は、公開テンプレート証明書と公開鍵証明書、及び公開鍵証明書と署名、というように、２段階で構成されている。
　このような２段階の検証手順を採用することで、ユーザＢは秘密鍵を紛失した場合でも、ユーザＢの生体情報を鍵として用いることで、公開鍵証明書を再発行することができる。生体情報はユーザＢの体内にある特徴であるため、通常の秘密鍵のように容易に紛失や漏洩が発生しにくい。
　このため、ユーザＢは秘密鍵の紛失や漏洩により新たなトランザクションを生成できなくなるリスクを低減することが可能となる。また、通常時は秘密鍵のみを保持しておけば、公知のブロックチェーンシステムと同様にトランザクションを生成できるため、生体情報を利用しても前記従来例のようにユーザＢの利便性が低下することもない。
　図１１は、ブロックチェーンシステムにおける、署名端末１０００及び公開テンプレートリポジトリ１２００、検証端末１１００のハードウェア構成を示すブロック図である。
　この図において、符号１０はＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、符号２０は主記憶装置、符号３０は補助記憶装置、符号４０は入力装置、符号５０は出力装置、符号６０は通信装置である。
　ＣＰＵ１０は、公開テンプレート生成部１０３０、鍵ペア生成部１０４０、公開鍵証明書生成部１０５０、ハッシュ値生成部１０６１、署名生成部１０７０、新トランザクション生成部１０７１、公開鍵失効申請書生成部１０８０、公開鍵証明書検証部１１２０、署名検証部１１４０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書検証部１２３０、証明書失効リスト生成部１２４０に対応するプログラムを実行する。
　主記憶装置２０は、コンピュータのメモリに相当する装置であり、公開テンプレート生成部１０３０、鍵ペア生成部１０４０、公開鍵証明書生成部１０５０、ハッシュ値生成部１０６１、署名生成部１０７０、新トランザクション生成部１０７１、公開鍵失効申請書生成部１０８０、公開鍵証明書検証部１１２０、署名検証部１１４０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書検証部１２３０、証明書失効リスト生成部１２４０に対応するプログラムを格納する。これらのプログラムをＣＰＵ１０で実行することで、各々の処理が実現する。
　補助記憶装置３０は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）などに代表される記憶装置であり、鍵格納部１０９１、公開テンプレート証明書格納部１０９２、公開テンプレート証明書格納部１２９０、証明書失効リスト格納部１２９１に相当する。各部が格納するデータは、補助記憶装置１１０３０上のデータとして蓄積される。
　入力装置４０は、センサやマウスキーボードなどを含む。出力装置５０は、主記憶装置１１０２０上の情報を出力するディスプレイなどを含む。通信装置６０は、署名端末１０００、公開テンプレートリポジトリ１２００、検証端末１１００がネットワーク１００と通信する際に使用される。
　ＣＰＵ１０は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、ＣＰＵ１０は、公開テンプレート生成プログラムに従って処理することで公開テンプレート生成部１０３０として機能する。他のプログラムについても同様である。さらに、ＣＰＵ１０は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
　各機能を実現するプログラム、テーブル等の情報は、補助記憶装置３０不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
　以上、実施例１によれば、ユーザの生体情報から公開テンプレート証明書を生成し、秘密鍵と公開鍵のペアを生成し、ユーザの生体情報を鍵として公開鍵へ生体署名を付与することで公開鍵証明書を生成し、ユーザの署名生成時に、秘密鍵を使ってメッセージに対して署名を付与し、署名検証時に、公開テンプレート証明書で公開鍵証明書の正当性を検証し、さらに公開鍵証明書でユーザの署名の正当性を検証し、鍵更新時に、再度秘密鍵と公開鍵のペアを生成し、生体情報を鍵として公開鍵へ署名を付与することで公開鍵証明書を再発行することが可能となる。
　また、トランザクション内に取引元の公開鍵証明書と、取引先の公開テンプレート証明書を含み、署名検証時には、既存（第１の）トランザクション１００１０の公開テンプレート証明書１００３０を用いて新（第２の）トランザクション１０１１０の公開鍵証明書１０１２０の正当性を検証し、その後、新トランザクション１０１１０に含まれる公開鍵証明書１０１２０を用いて、新トランザクション１０１１０に含まれるユーザ署名１０１７０の正当性を検証することで、ブロックチェーンシステムを構築できる。
　さらに、公開テンプレート証明書に対して認証局の秘密鍵による署名を付与し、署名検証時には、認証局の秘密鍵に対応する認証局の公開鍵で正当性を検証することが可能となる。
　第２の実施例は、ブロックチェーンシステムのユーザが自らの秘密鍵の紛失または漏洩時に、署名端末１０００で秘密鍵を失効させて新たな秘密鍵を再発行して、継続的にブロックチェーンシステムを利用することを可能とするシステムを、公開テンプレートリポジトリ１２００を利用せずに構成するものである。
　前記実施例１では、公開テンプレートリポジトリ１２００を信頼できる第三者機関としておき、公開テンプレートリポジトリ１２００を介して公開テンプレート証明書や証明書失効リストの発行を行った。
　このようなブロックチェーンシステムは、公開テンプレートリポジトリ１２００が認証局として機能することで、信頼性の高い公開テンプレート証明書や証明書失効リストを発行することができた。しかしながら、ブロックチェーンシステムは信頼できる第三者機関を置かずに低コストでトランザクションの管理を実現することも望まれており、運用に一定のコストを要する認証局の構築を行った場合、ブロックチェーンシステムの運用コストは増大する。
　そこで本実施例２では、公開テンプレートリポジトリ１２００を利用せずに、前記実施例１と同様に秘密鍵の紛失または漏洩時に、秘密鍵を失効させて新たな秘密鍵を再発行し、継続的にトランザクション生成を可能とする。本実施例２は、前記実施例１の図２、図６、図７の処理と、図９Ａ～図９Ｃのデータを変更し、図１の公開テンプレートリポジトリ１２００と図９Ｄの証明書失効リストを削除した。その他の構成は前記実施例１と同様である。以下、前記実施例１との差分について説明する。
　図１２は、実施例２のブロックチェーンシステムの一例を示すブロック図である。図１２のブロックチェーンシステムにおいて、前記実施例１の公開テンプレートリポジトリ１２００で稼働していた公開テンプレート証明書生成部を署名端末１０００で稼働させ、公開鍵失効申請書９２００を署名端末１０００で保持する点が前記実施例１と相違する。
　図１３は、実施例２の公開テンプレート証明書の初期登録の処理の一例を示すフローチャートである。本実施例２では、前記実施例１の図２の処理から公開テンプレートリポジトリ１２００の処理を削除し、署名端末１０００で公開テンプレート証明書の生成処理を実行する。
　ステップＳ２０１０では、前記実施例１と同様に署名端末１０００が初期登録を行う。次に、公開テンプレート証明書生成部１０９０がステップＳ２０３５で公開テンプレート証明書を生成する。この処理は、公開テンプレート証明書生成部１０９０が公開テンプレートに対して署名を付与して公開テンプレート証明書を生成する。そして、ステップＳ２０４０では、公開テンプレート証明書生成部１０９０が公開テンプレート証明書を公開テンプレート証明書格納部１０９２へ登録する。
　図１５は、実施例２の公開テンプレート証明書９０００の一例を示す図である。実施例２の公開テンプレート証明書９０００は、前記実施例１の図９Ａの公開テンプレートシリアル番号９０２０を削除したものである。
　発行者９０４０は、公開テンプレート証明書を発行する主体として、前記実施例１の認証局に代わって署名端末１０００の識別子を格納する。また、公開テンプレート証明書の署名値９０９１は、認証局の署名に替わり、ユーザの生体情報（公開テンプレート）を鍵とする生体署名とする。このように公開テンプレート証明書に対して自己の生体署名を付与することで、第三者の改ざんを検知できるようになる。
　また、前記実施例１の図６に示したトランザクション検証（Ｓ４２２０）では、公開テンプレート証明書検証Ｓ６０１０において、署名値９０９１を認証局の公開鍵を用いて検証した。本実施例２では、署名値９０９１を、公開テンプレート９０８０を用いて正当性を検証する。これにより、公開テンプレート証明書が改ざんされていないことが検証できる。本実施例２におけるＳ６０２０以降の処理は、実施例１と同様である。
　図１４は、実施例２の公開鍵証明書を失効させ処理の一例を示すフローチャートである。前記実施例１の図７では、公開テンプレートリポジトリ１２００において公開鍵失効申請書の正当性の検証（Ｓ７１２０）を行い、検証に成功したときに証明書失効リストを発行した（Ｓ７１４０）。
　本実施例２では、公開テンプレートリポジトリ１２００を削除したので、署名端末１０００がステップＳ７０５０にて公開鍵失効申請書を生成する。検証端末１１００は、生成した公開鍵失効申請書を格納しておき、トランザクションの検証時に活用する。
　図１６は、実施例２の公開鍵証明書９１００を示す図である。
　本実施例２では、前記実施例１の図９Ｂに示した公開鍵証明書９１００の公開テンプレートシリアル番号９１２０を公開テンプレート証明書に含めず、代わりに公開テンプレート９１２０Ａに公開テンプレート９０８０そのもの、または公開テンプレートのハッシュ値を格納する。その他の構成は前記実施例１と同様である。
　図１７は、実施例２の公開鍵失効申請書９２００を示す図である。
　本実施例２では、前記実施例１の図９Ｃに示した公開鍵失効申請書９２００の公開テンプレートシリアル番号９２１０を公開失効申請書に含めず、代わりに公開テンプレート９２１０Ａに公開テンプレート９０８０そのもの、または公開テンプレートのハッシュ値を格納する。その他の構成は前記実施例１と同様である。
　また、本実施例２では、前記実施例１の図９Ｄに示した証明書失効リスト９３００を発行しない。
　以上のように処理の手順を変更することで、本実施例２では公開テンプレートリポジトリ１２００を利用せずに、秘密鍵の紛失や漏洩時にも継続的に利用できるブロックチェーンシステムを実現する。
　実施例２によれば、公開テンプレートを用いて公開テンプレート証明書に含まれる生体署名の正当性を検証することで、認証局を使用しないブロックチェーンシステムでもユーザの生体情報によって各証明書の正当性を検証することができ、認証局に要するコストを削減することが可能となる。
　第３の実施例は、前記実施例１のブロックチェーンシステムに生体情報を取得して鍵ペアと公開テンプレートを生成する登録端末を加えたブロックチェーンシステムを示す。図１８は、実施例３のブロックチェーンシステムの一示すブロック図である。
　ブロックチェーンシステムは、ユーザＡ～Ｃの鍵と公開テンプレート証明書を登録する登録端末１４００と、トランザクションの正当性を検証する検証端末１１００と、公開テンプレート証明書を生成する公開テンプレートリポジトリ１２００と、トランザクションを生成するユーザ端末１３００－Ａ～１３００－Ｃがネットワーク１００を介して接続される。
　検証端末１１００と公開テンプレートリポジトリ１２００は、前記実施例１と同様である。ユーザ端末１３００－Ａ～１３００－Ｃは、前記実施例１の署名端末１０００と同様であり、ユーザ端末の全体を符号１３００で表す。
　登録端末１４００は、前記実施例１の署名端末１０００からトランザクションを生成するための機能部を省略したもので、図１に示した記録情報取得部１０６０、署名生成部１０７０、ハッシュ値生成部１０６１、新トランザクション生成部１０７１を省略した。その他の構成は前記実施例１と同様である。
　本実施例３のブロックチェーンシステムでは、ブロックチェーンシステムのユーザＡ～Ｃは、まず、登録端末１４００で生体情報を取得して公開テンプレート証明書と鍵を登録する。次に、登録端末１４００から各ユーザＡ～Ｃが使用するユーザ端末１３００－Ａ～１３００－Ｃに各自の鍵と各証明書を送信して格納する。その後、各ユーザは公開鍵などの送受信を行ってからトランザクションの送信を行う。なお、鍵ペアと証明書の送信は、オフラインで行うようにしても良い。また、前記実施例１と同様に、公開鍵証明書をユーザ端末１３００で生成するようにしてもよい。
　図１９は、ブロックチェーンシステムで行われる登録処理の一例を示すシーケンス図である。この処理は、前記実施例１の図２、図３と同様で、ユーザがブロックチェーンシステムを利用する初回に行う登録処理である。以下ではユーザＡの登録処理の一例を示す。
　まず、登録端末１４００では生体情報取得部１０２０が、ユーザＡの生体情報を取得する（Ｓ３０１）。
　公開テンプレート生成部１０３０は、ステップＳ３０１で取得した生体情報に対して一方向性変換を施すことで、公開テンプレートを生成する（Ｓ３０２）。公開テンプレート生成部１０３０は、生成した公開テンプレートを公開テンプレートリポジトリ１２００へ送信する（Ｓ３０３）。
　登録端末１４００の鍵ペア生成部１０４０は、秘密鍵と公開鍵の鍵ペアを生成する（Ｓ３０４）。
　登録端末１４００の公開鍵証明書生成部１０５０は、生成した公開鍵に対して、ステップＳ３０１で取得した生体情報を鍵とする生体署名を付与することで、公開鍵証明書を生成する（Ｓ３０５）。
　登録端末１４００は、秘密鍵、公開鍵および公開鍵証明書を鍵格納部１０９１に格納する（Ｓ３０６）。
　次に、公開テンプレートリポジトリ１２００では、公開テンプレート証明書生成部１２２０は受信した公開テンプレートに署名を付与して公開テンプレート証明書を生成する（Ｓ３０９）。本実施例３は前記実施例１と同様に認証局の秘密鍵を用いて署名する。
　公開テンプレートリポジトリ１２００は、生成した公開テンプレート証明書を公開テンプレート証明書格納部１２９０へ登録し（Ｓ３１０）、さらに、公開テンプレート証明書を登録端末１４００に送信する（Ｓ３１１）。登録端末１４００は、公開テンプレート証明書を受信すると、公開テンプレート証明書格納部１０９２へ登録する（Ｓ３０７）。
　次に、登録端末１４００は、ユーザＡが利用するユーザ端末１３００－Ａに、鍵ペアと公開鍵証明書と公開テンプレート証明書を送信する（Ｓ３０８）。ユーザ端末１３００－Ａは、受信した鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録し、公開テンプレート証明書を公開テンプレート証明書格納部１０９２へ登録する（Ｓ３１２）。
　次に、ユーザ端末１３００－Ａは、トランザクションを送信するユーザ端末１３００－Ｂ等へ公開鍵と公開テンプレートを送信する（Ｓ３１３）。ユーザ端末１３００－Ａは、受信した公開鍵と公開テンプレートを格納へ登録する（Ｓ３１４）。
　以上により、鍵ペアと公開鍵証明書が生成されて登録処理が完了し、トランザクションを送受する準備が完了する。
　図２０は、ブロックチェーンシステムで行われるトランザクションの検証処理の一例を示すシーケンス図である。この処理は、前記実施例１の図４～図６と同様であり、図２０では、ユーザＢが送信した既存トランザクションをユーザＡが受信し、ユーザＡが新たなトランザクションを生成してユーザＣに送信する際に検証を行う例を示す。
　まず、ユーザ端末１３００－Ｂが既存トランザクションを送信し、ユーザ端末１３００－Ａが受信する（Ｓ４０１）。なお、トランザクションの送信は、ブロックチェーンシステム内でブロードキャストし、公開鍵や公開テンプレートの送信にはＰ２Ｐネットワークを利用する。
　ユーザ端末１３００－Ａは、既存トランザクションにユーザＡの署名を加えて新たなトランザクションを生成し（Ｓ４０２）、ユーザ端末１３００－Ｃを宛て先としてブロードキャストする（Ｓ４０３）。検証端末１１００は、ブロードキャストされた新トランザクションを受信して検証を開始する。
　検証端末１１００は、新トランザクションに含まれる公開テンプレート証明書の正当性を検証する（Ｓ４０４）。公開テンプレート証明書には、認証局の秘密鍵で生成した署名値が付与されており、検証端末１１００では当該署名値を認証局の公開鍵を用いて正当性を検証する。これにより、検証端末１１００は、公開テンプレート証明書が確かに認証局によって発行されたものであることを検証できる。
　次に、検証端末１１００は、新トランザクションに含まれる公開鍵証明書を、既存トランザクションに含まれる公開テンプレート証明書を用いて正当性を検証する（Ｓ４０５）。公開鍵証明書には生体情報を鍵とする生体署名が付与されている。この生体署名が、確かに本人が付与したものか否かを、公開テンプレート証明書を用いて正当性を検証する。
　これにより、検証端末１１００は、既存トランザクションに含まれる公開テンプレート証明書を生成したユーザと、新トランザクションに含まれる公開鍵証明書を生成したユーザが同一であることが検証できる。さらに、ステップＳ４０５では、公開鍵証明書が証明書失効リスト９３００に含まれていないことを検証する。
　次に、検証端末１１００では、署名の正当性の検証を行う（Ｓ４０６）。この処理は、前記実施例１に示した図６のステップＳ６０５０～６０７０と同様であり、検証端末１１００はハッシュ値を生成して、生成したハッシュ値と公開鍵証明書を用いて、署名の正当性を検証する。
　検証端末１１００は、公開テンプレート証明書と公開鍵証明書及び署名の検証結果をユーザ端末１３００－Ａ、１３００－Ｃに通知する。
　以上により、検証端末１１００は、トランザクションの内容を検証することができる。
　図２１は、ブロックチェーンシステムで行われる鍵の再発行処理の一例を示すシーケンス図である。この処理は、前記実施例１の図７、図８と同様であり、図２１では、ユーザＡが秘密鍵を紛失した例を示す。
　ユーザ端末１３００－ＡのユーザＡは、秘密鍵を紛失したので（Ｓ５０１）、登録端末１４００で鍵の再発行処理を開始する。登録端末１４００は、ユーザＡの公開鍵証明書と公開テンプレート証明書を鍵格納部１０９１及び公開テンプレート証明書格納部１０９２から取得して公開鍵失効申請書を生成し（Ｓ５０２）、公開テンプレートリポジトリ１２００へ送信する（Ｓ５０３）。
　公開テンプレートリポジトリ１２００は、公開鍵失効申請書の正当性を検証する（Ｓ５０３）。この検証は、公開テンプレートリポジトリ１２００が、公開鍵失効申請書に付与された署名値が正しいことを、公開テンプレート証明書を用いて検証する。検証が成功した場合、公開テンプレートリポジトリ１２００は、公開鍵失効リストを発行する（Ｓ５０４）。公開テンプレートリポジトリ１２００は、公開鍵失効リストを証明書失効リスト格納部１２９１へ登録し、登録端末１４００に送信する。
　登録端末１４００は、公開鍵失効リストを受信した後に、ユーザＡの生体情報を取得する（Ｓ５０５）。登録端末１４００は、公開テンプレート証明書の生体署名を用いて、公開テンプレート証明書を生成した際に元にした生体情報と、取得した生体情報とが同一人物から取得したものであるかを検証し、同一人物の場合は検証成功とする。
　検証が成功した場合には、登録端末１４００が、前記実施例１と同様に鍵ペアを生成し（Ｓ５０７）、公開鍵に署名を付与して公開鍵証明書を生成する（Ｓ５０８）。登録端末１４００は、鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録してから（Ｓ５０９）、鍵ペアと公開鍵証明書をユーザＡのユーザ端末１３００－Ａに送信する（Ｓ５１０）。
　ユーザ端末１３００－Ａは、古い鍵ペアと公開鍵証明書を削除し、受信した新たな鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録する（Ｓ５１１）。次に、ユーザ端末１３００－Ａは、トランザクションの送受を行うユーザ端末１３００－Ｂに公開鍵を送信する（Ｓ５１２）。
　ユーザ端末１３００－Ｂは、ユーザＡの古い公開鍵を削除して、新たに受信した公開鍵を鍵格納部１０９１へ登録する（Ｓ５１３）。
　以上のように、本実施例３では、登録端末１４００を用いて取得したユーザの生体情報を鍵として公開鍵へ署名を付与することで公開鍵証明書を再発行することができる。本実施例３では、例えば、ブロックチェーンシステムを管理する組織に登録端末１４００を設置して、ブロックチェーンシステムの管理者などがユーザの本人確認を行ってから生体情報を取得することが可能となる。これにより、本人のなりすましによる登録を抑制することができる。
　なお、登録端末１４００と公開テンプレートリポジトリ１２００は、ひとつの計算機で構成することができる。この場合、登録部（公開鍵証明書生成部１４５０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書生成部１０８０）をひとつの計算機で提供することができる。あるいは、登録端末１４００と公開テンプレートリポジトリ１２００と検証端末１１００を、ひとつの計算機で構成してもよい。この場合、登録部と検証部（公開鍵証明書検証部１１２０）をひとつの計算機で提供することができる。
　第４の実施例は、前記実施例１または実施例３のブロックチェーンシステムのトランザクションの一部を変更したもので、その他の構成は前記実施例１または実施例３と同様である。
　図２２は、実施例４のブロックチェーンのデータ構造の一例を示すブロック図である。前記実施例１の図１０に示したトランザクションのうち、公開テンプレート証明書１００３０、１０１３０に代わって、公開テンプレートシリアル番号（Ｓ／Ｎ）１００３１、１０１３１を用いるようにした点が、本実施例４における変更点である。
　公開テンプレートシリアル番号１００３１（１０１３１）は、公開テンプレートリポジトリ１２００の公開テンプレート証明書の生成時に、公開テンプレート証明書に対応付けた値として付与することができる。あるいは、登録端末１４００で公開テンプレートを生成する際に、公開テンプレートに対応付けた値として付与することができる。公開テンプレートシリアル番号１００３１（１０１３１）は、ブロックチェーンシステム内でユニークな識別子であれば良い。
　なお、公開テンプレートリポジトリ１２００は、公開テンプレート証明書と公開テンプレートシリアル番号を関連付けて公開テンプレート証明書格納部１２９０へ格納する。
　既存トランザクション１００１０や新トランザクション１０１１０の正当性を検証する際には、例えば、検証端末１１００が、公開テンプレートシリアル番号１００３１（１０１３１）に対応する公開テンプレート証明書を公開テンプレートリポジトリ１２００に要求すればよい。
　以上のように、公開テンプレート証明書に代わって、ユーザを特定する識別子として公開テンプレートシリアル番号１００３１（１０１３１）をトランザクションに設定することでトランザクションのサイズを抑制する。そして、検証端末１１００では、トランザクションを受け付けると、公開テンプレートシリアル番号１００３１を取得して公開テンプレートリポジトリ１２００に検索させて取得することができる。
　＜まとめ＞
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
　また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims (15)

  1. 　プロセッサとメモリを備えた計算機で署名を検証する署名検証システムであって、
    　ユーザの生体情報を取得する生体情報取得部と、
    　前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、
    　秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、
    　前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、
    　前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する検証部と、
    を有することを特徴とする署名検証システム。
  2. 　請求項１に記載の署名検証システムであって、
    　前記トランザクションは、
    　取引元の公開鍵証明書と取引先の公開テンプレート証明書とを含み、
    　前記検証部は、
    　第１のトランザクションの次に第２のトランザクションを受け付けて、前記第１のトランザクションの公開テンプレート証明書を用いて前記第２のトランザクションの公開鍵証明書を検証し、前記第２のトランザクションに含まれる公開鍵証明書を用いて前記第２のトランザクションに含まれる署名を検証することを特徴とする署名検証システム。
  3. 　請求項１に記載の署名検証システムであって、
    　前記公開テンプレート証明書を第１の識別子と対応付けて格納する公開テンプレート証明書格納部をさらに有し、
    　前記トランザクションは、
    　前記公開テンプレート証明書に代わって、前記第１の識別子を格納し、
    　前記検証部は、
    　前記トランザクションの第１の識別子を取得して、前記公開テンプレート証明書格納部から前記第１の識別子に対応する公開テンプレート証明書を取得することを特徴とする署名検証システム。
  4. 　請求項１に記載の署名検証システムであって、
    　前記トランザクションは、
    　前記公開テンプレート証明書に認証局の秘密鍵で生成した署名値を含み、
    　前記検証部は、
    　前記認証局の公開鍵を用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証システム。
  5. 　請求項１に記載の署名検証システムであって、
    　前記トランザクションは、
    　前記公開テンプレート証明書に生体情報を鍵とする署名値と、前記生体情報から生成された公開テンプレートを含み、
    　前記検証部は、
    　前記トランザクションから前記公開テンプレートを取得し、当該公開テンプレートを用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証システム。
  6. 　請求項１に記載の署名検証システムであって、
    　前記公開鍵証明書を特定する第２の識別子と、前記生体情報を鍵とする生体署名を付与した公開鍵失効申請書を発行する公開鍵失効申請書生成部をさらに有することを特徴とする署名検証システム。
  7. 　請求項６に記載の署名検証システムであって、
    　前記公開鍵証明書生成部は、
    　前記発行された公開鍵失効申請書に対応する公開テンプレート証明書を取得し、前記公開テンプレート証明書を利用するユーザの生体情報を取得し、前記公開テンプレート証明書を生成した生体情報と前記取得した生体情報が一致していれば、新たな鍵ペアと新たな公開鍵証明書を生成することを特徴とする署名検証システム。
  8. 　請求項１に記載の署名検証システムであって、
    　前記計算機は、
    　鍵ペアと公開鍵証明書を生成する登録端末と、トランザクションを受け付け検証する検証端末と、公開テンプレート証明書を生成する公開テンプレートリポジトリと、を含み。
    　前記登録端末は、前記生体情報取得部と、前記鍵ペア生成部と、前記公開鍵証明書生成部とを有し、
    　前記検証端末は、前記検証部を有し、
    　前記公開テンプレートリポジトリは、前記公開テンプレート証明書生成部を有することを特徴とする署名検証システム。
  9. 　プロセッサとメモリを備えた計算機で署名を検証する署名検証方法であって、
    　前記計算機が、ユーザの生体情報を取得する第１のステップと、
    　前記計算機が、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する第２のステップと、
    　前記計算機が、秘密鍵と公開鍵のペアを生成する第３のステップと、
    　前記計算機が、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する第４のステップと、
    　前記計算機が、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付ける第５のステップと、
    　前記計算機が、前記トランザクションに含まれる前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する第６のステップと、
    を含むことを特徴とする署名検証方法。
  10. 　請求項９に記載の署名検証方法であって、
    　前記トランザクションは、
    　取引元の公開鍵証明書と取引先の公開テンプレート証明書とを含み、
    　前記第５のステップは、
    　第１のトランザクションの次に第２のトランザクションを受け付けて、
    　前記第６のステップは、
    　前記第１のトランザクションの公開テンプレート証明書を用いて前記第２のトランザクションの公開鍵証明書を検証し、前記第２のトランザクションに含まれる公開鍵証明書を用いて前記第２のトランザクションに含まれる署名を検証することを特徴とする署名検証方法。
  11. 　請求項９に記載の署名検証方法であって、
    　前記第２のステップは、
    　前記公開テンプレート証明書を第１の識別子と対応付けて公開テンプレート証明書格納部へ格納し、
    　前記トランザクションは、
    　前記公開テンプレート証明書に代わって、前記第１の識別子を格納し、
    　前記第６のステップは、
    　前記トランザクションの第１の識別子を取得して、前記公開テンプレート証明書格納部から前記第１の識別子に対応する公開テンプレート証明書を取得することを特徴とする署名検証方法。
  12. 　請求項９に記載の署名検証方法であって、
    　前記トランザクションは、
    　前記公開テンプレート証明書に認証局の秘密鍵で生成した署名値を含み、
    　前記第６のステップは、
    　前記認証局の公開鍵を用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証方法。
  13. 　請求項９に記載の署名検証方法であって、
    　前記トランザクションは、
    　前記公開テンプレート証明書に生体情報を鍵とする署名値と、前記生体情報から生成された公開テンプレートを含み、
    　前記第６のステップは、
    　前記トランザクションから前記公開テンプレートを取得し、当該公開テンプレートを用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証方法。
  14. 　請求項９に記載の署名検証方法であって、
    　前記計算機が、前記公開鍵証明書を特定する第２の識別子と、前記生体情報を鍵とする生体署名を付与した公開鍵失効申請書を発行する第７のステップをさらに含むことを特徴とする署名検証方法。
  15. 　プロセッサとメモリを備えた計算機を制御するプログラムを格納した記憶媒体であって、
    　トランザクションに含めるメッセージを取得する第１のステップと、
    　前記トランザクションに含まれる情報のハッシュ値を生成する第２のステップと、
    　前記ハッシュ値に対して予め生成した秘密鍵を用いて署名を付与する第３のステップと、
    　生体情報に所定の処理を加えて予め生成された公開テンプレート証明書を取得する第４のステップと、
    　前記生体情報を鍵として前記秘密鍵に対応する公開鍵へ生体署名を付与した公開鍵証明書を取得する第５のステップと、
    　前記公開テンプレート証明書と、前記公開鍵証明書と、前記メッセージと、前記署名とを含むトランザクションを生成する第６のステップと、
    を前記計算機に実行させるためのプログラムを格納した非一時的な計算機読み取り可能な記憶媒体。
PCT/JP2017/018291 2016-07-21 2017-05-16 署名検証システム、署名検証方法及び記憶媒体 WO2018016160A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG11201900414WA SG11201900414WA (en) 2016-07-21 2017-05-16 Signature verification system, signature verification method, and storage medium
US16/318,501 US11018876B2 (en) 2016-07-21 2017-05-16 Signature verification system, signature verification method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-143152 2016-07-21
JP2016143152A JP6550353B2 (ja) 2016-07-21 2016-07-21 署名検証システム、署名検証方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2018016160A1 true WO2018016160A1 (ja) 2018-01-25

Family

ID=60993324

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/018291 WO2018016160A1 (ja) 2016-07-21 2017-05-16 署名検証システム、署名検証方法及び記憶媒体

Country Status (4)

Country Link
US (1) US11018876B2 (ja)
JP (1) JP6550353B2 (ja)
SG (1) SG11201900414WA (ja)
WO (1) WO2018016160A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109067553A (zh) * 2018-10-17 2018-12-21 杭州趣链科技有限公司 一种基于智能合约的区块链分布式证书的管理方法
WO2019163040A1 (ja) * 2018-02-22 2019-08-29 株式会社ゼタント アクセス管理システム、及びそのプログラム
JP2019219780A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 個人情報管理システム、サービス提供システム、方法およびプログラム
JP2020035106A (ja) * 2018-08-28 2020-03-05 株式会社リップル・マーク 仮想通貨管理システム、仮想通貨管理方法及び仮想通貨管理プログラム
JP2020123856A (ja) * 2019-01-30 2020-08-13 株式会社日立製作所 署名システム、署名方法及びプログラム
WO2021038684A1 (ja) * 2019-08-26 2021-03-04 日本電気株式会社 情報処理装置、ノード、データ記録方法及びコンピュータ可読媒体
JP2021103518A (ja) * 2019-12-24 2021-07-15 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド プライバシーデータの処理方法、プライバシーデータの処理装置、機器及び媒体

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3054905B1 (fr) * 2016-08-04 2019-10-18 Safran Identity & Security Procede de generation de cle et procede de controle d'acces
EP3613171B1 (en) * 2017-05-30 2021-06-30 Siemens Aktiengesellschaft Industrial network using a blockchain for access control, and access control method
JP6340120B1 (ja) * 2017-06-16 2018-06-06 アイビーシー株式会社 デバイスプロビジョニングシステム
CN112865982A (zh) * 2017-07-26 2021-05-28 创新先进技术有限公司 数字证书管理方法、装置及电子设备
FR3070077A1 (fr) * 2017-08-09 2019-02-15 Orange Procede et serveur de certification d'un document electronique
US11018870B2 (en) * 2017-08-10 2021-05-25 Visa International Service Association Biometric verification process using certification token
US10938572B2 (en) * 2018-01-10 2021-03-02 International Business Machines Corporation Revocable biometric-based keys for digital signing
JP6841781B2 (ja) * 2018-03-12 2021-03-10 株式会社日立製作所 認証サーバ装置、認証システム及び認証方法
US11700132B2 (en) 2018-05-02 2023-07-11 Cable Television Laboratories, Inc. Systems and methods for secure event and log management
CN109146481B (zh) * 2018-08-23 2020-09-08 泰链（厦门）科技有限公司 区块链钱包的账户私钥自动导入方法、介质、装置及区块链系统
JP6952661B2 (ja) * 2018-08-30 2021-10-20 株式会社東芝 情報処理装置、通信機器、情報処理システム、情報処理方法、および情報処理プログラム
AU2019346668A1 (en) * 2018-09-28 2021-04-29 Shelterzoom Corp. Smart contracts
JP7032296B2 (ja) * 2018-12-26 2022-03-08 株式会社日立製作所 トランザクション判定装置、トランザクション判定方法、及びトランザクション判定プログラム
US11038878B2 (en) * 2019-03-14 2021-06-15 Hector Hoyos Computer system security using a biometric authentication gateway for user service access with a divided and distributed private encryption key
JP6650157B1 (ja) 2019-05-08 2020-02-19 株式会社モールサービス 情報管理システム、情報管理方法及び情報管理プログラム
WO2021053749A1 (ja) * 2019-09-18 2021-03-25 日本電気株式会社 情報照合システム、クライアント端末、サーバ、情報照合方法、及び情報照合プログラム
CN110611569B (zh) * 2019-09-24 2022-06-14 腾讯科技（深圳）有限公司 一种认证方法及相关设备
EP4073655A4 (en) 2019-12-10 2023-09-27 Hitachi, Ltd. METHOD AND DEVICE FOR GENERATING TEST ENVIRONMENTS FOR BLOCKCHAIN SYSTEMS
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
US20230308435A1 (en) * 2020-06-22 2023-09-28 Nec Corporation Authentication system, authentication terminal, method for controlling authentication system, method for controlling authentication terminal, and storage medium
CN114710289B (zh) * 2022-06-02 2022-09-02 确信信息股份有限公司 物联网终端安全注册和接入方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009017198A1 (ja) * 2007-08-01 2009-02-05 Kabushiki Kaisha Toshiba 検証装置及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2377782A (en) * 2001-07-21 2003-01-22 Ibm Method and system for the communication of assured reputation information
US9832019B2 (en) * 2009-11-17 2017-11-28 Unho Choi Authentication in ubiquitous environment
JP5707311B2 (ja) 2011-12-12 2015-04-30 株式会社日立製作所 生体署名システム
FR2996942B1 (fr) * 2012-10-11 2016-01-08 Morpho Procede de generation de cle de signature ameliore

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009017198A1 (ja) * 2007-08-01 2009-02-05 Kabushiki Kaisha Toshiba 検証装置及びプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KENTA TAKAHASHI ET AL.: "Template kokaigata seitai ninsho kiban", THE 29TH SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY (SCIS), 1F1-3, 30 January 2012 (2012-01-30), pages 1 - 8 *
YASUYUKI FUCHITA: "Tokushu : Innovation to Kin'yu block chain to kin'yu torihiki no kakushin", NOMURA CAPITAL MARKETS QUARTERLY, vol. 19, no. 2, 74, 1 November 2015 (2015-11-01), pages 11 - 35 *
YUTA YONEYAMA ET AL.: "Fuzzy signature scheme for biometric digital signature", THE 29TH SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY (SCIS 2012), 4A1-1, 30 January 2012 (2012-01-30), pages 1 - 7, XP055281883 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019163040A1 (ja) * 2018-02-22 2019-08-29 株式会社ゼタント アクセス管理システム、及びそのプログラム
JPWO2019163040A1 (ja) * 2018-02-22 2021-01-07 株式会社ゼタント アクセス管理システム、及びそのプログラム
JP2019219780A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 個人情報管理システム、サービス提供システム、方法およびプログラム
JP2020035106A (ja) * 2018-08-28 2020-03-05 株式会社リップル・マーク 仮想通貨管理システム、仮想通貨管理方法及び仮想通貨管理プログラム
CN109067553B (zh) * 2018-10-17 2021-06-25 杭州趣链科技有限公司 一种基于智能合约的区块链分布式证书的管理方法
CN109067553A (zh) * 2018-10-17 2018-12-21 杭州趣链科技有限公司 一种基于智能合约的区块链分布式证书的管理方法
JP2020123856A (ja) * 2019-01-30 2020-08-13 株式会社日立製作所 署名システム、署名方法及びプログラム
JP7061083B2 (ja) 2019-01-30 2022-04-27 株式会社日立製作所 署名システム、署名方法及びプログラム
WO2021038684A1 (ja) * 2019-08-26 2021-03-04 日本電気株式会社 情報処理装置、ノード、データ記録方法及びコンピュータ可読媒体
JPWO2021038684A1 (ja) * 2019-08-26 2021-03-04
JP7302664B2 (ja) 2019-08-26 2023-07-04 日本電気株式会社 情報処理装置、データ記録システム、データ記録方法及びプログラム
JP2021103518A (ja) * 2019-12-24 2021-07-15 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド プライバシーデータの処理方法、プライバシーデータの処理装置、機器及び媒体
JP7069286B2 (ja) 2019-12-24 2022-05-17 バイドゥ オンライン ネットワーク テクノロジー（ペキン） カンパニー リミテッド プライバシーデータの処理方法、プライバシーデータの処理装置、機器及び媒体

Also Published As

Publication number Publication date
JP6550353B2 (ja) 2019-07-24
US20190238344A1 (en) 2019-08-01
US11018876B2 (en) 2021-05-25
JP2018014622A (ja) 2018-01-25
SG11201900414WA (en) 2019-02-27

Similar Documents

Publication Publication Date Title
WO2018016160A1 (ja) 署名検証システム、署名検証方法及び記憶媒体
CN109951489B (zh) 一种数字身份认证方法、设备、装置、系统及存储介质
CN109522698B (zh) 基于区块链的用户认证方法及终端设备
US11917074B2 (en) Electronic signature authentication system based on biometric information and electronic signature authentication method
KR101863953B1 (ko) 전자 서명 서비스 시스템 및 방법
CN114553439B (zh) 基于身份信息的加密密钥管理
JP2021517412A (ja) デジタル証明書の検証方法並びにその、装置、コンピュータ機器並びにコンピュータプログラム
JP7139414B2 (ja) 認証端末、認証装置、並びにこれを用いた認証方法及びシステム
JP2007148470A (ja) 処理装置、補助情報生成装置、端末装置、認証装置及び生体認証システム
JP5038807B2 (ja) 検証装置及びプログラム
KR102284396B1 (ko) 생체 정보 기반의 pki 키 생성 방법 및 이를 이용한 키 생성 장치
KR101858653B1 (ko) 블록체인 데이터베이스 및 이와 연동하는 머클 트리 구조를 통해 모바일 아이디를 이용하여 사용자를 인증하는 방법, 단말 및 이를 이용한 서버
US11082236B2 (en) Method for providing secure digital signatures
JP6609048B2 (ja) 生体署名システム及び生体証明書登録方法
JP2020529745A (ja) 暗号動作のセキュアな実行
JP6841781B2 (ja) 認証サーバ装置、認証システム及び認証方法
TW201729135A (zh) 認證裝置、認證系統以及認證程式產品
JP6852292B2 (ja) 証明書生成システム、情報処理装置、証明書生成装置、証明書生成方法、及びプログラム
JP7061083B2 (ja) 署名システム、署名方法及びプログラム
JP6398483B2 (ja) 電子署名装置、電子署名システム、電子署名方法及びプログラム
WO2024075647A1 (ja) 処理権限移譲システム及び処理権限移譲方法
JP7341207B2 (ja) 端末およびその制御方法、並びにプログラム
WO2022091902A1 (ja) Ｉｃカード、携帯可能電子装置及び発行装置
JP7416205B2 (ja) グループ管理装置、グループ管理方法及びプログラム
JP2023125727A (ja) テンプレート管理システム及びテンプレート管理方法

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17830680

Country of ref document: EP

Kind code of ref document: A1