JP5346111B2 - Verification server, program, and verification method - Google Patents

Description

  The present invention relates to a technique for performing certificate verification processing.

  When sending electronic data such as electronic documents, the sender's electronic signature (hereinafter also referred to as “signature”) and public key certificate (hereinafter also referred to as “certificate”) are applied to the target electronic data. Attaching is done. The receiver who receives the electronic data attached with such a signature and certificate verifies the attached signature and certificate, confirms that the sent data has not been tampered with, and is surely the sender. Confirm that it is electronic data sent from the person.

  The issuance and verification of public key certificates are performed on a public key infrastructure, and the standard specifications thereof are defined in RFC5280 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile) and the like. Among these, for certificate validation, as specified in RFC 6280, Chapter 6 (Certificate Path Validation), the recipient (hereinafter also referred to as “verifier”) is the certificate authority (Certificate Authority) A certification path up to a certificate to be verified is constructed starting from a certificate (also referred to as “CA”) and the constructed certification path is verified.

  In the certificate verification process, when there are a large number of certificate authorities and each has a complicated configuration in which they are connected by mutual authentication, the construction of the certification path and the verification of the certification path are complicated processes. For this reason, a server (hereinafter referred to as “verification server”) that provides a service for performing certificate verification processing and transmitting the verification result to the verifier is used instead of the verifier device, and its standard protocol is RFC5055. (Server-Based Certificate Validation Protocol) When the verification server receives the certificate verification request from the verifier, the verification server constructs the certification path between the certification authority trusted by the verifier and the verification target certificate, and verifies the constructed certification path. A signature and a certificate of the verification server are attached to the result and transmitted to the verifier. When the verifier receives the verification result from the verification server, the verifier verifies the signature and certificate of the verification server attached to the verification result, and confirms that the verification result is reliable.

  In such a verification server, a signature verification process of a certificate or a certificate revocation list (hereinafter referred to as “CRL”) in a verification process of a certification path, a signature generation process of a verification server for a verification result, etc. It is necessary to carry out cryptographic operations. In order to reduce the processing load of such cryptographic operations, devices (Hardware Security Module: hereinafter referred to as “HSM”) as described in Non-Patent Documents 1, 2, and 3 are used.

SafeNet, "Luna SA 4.2", [online], SafeNet, P.1, [Search January 21, 2008], Internet <http://www.safenet-inc.com/library/3/Luna_SA .pdf> SafeNet, "Luna PCM 2.2", [online], SafeNet, P.1, [Search January 21, 2008], Internet <http://www.safenet-inc.com/library/3/LunaPCM .pdf> nCipher, “netHSM”, [online], nCipher, P.M. 1. [Search January 21, 2008], Internet <http://www.ncipher.com/uploads/resources/nethsm.pdf>

  When performing cryptographic operation processing in the verification server using the HSM as described in Non-Patent Documents 1, 2, and 3 above, the processing performance of the verification server is better than the processing performance of the HSM or a large number of verification requests are accepted. In such a case, the processing in the HSM becomes a bottleneck, and the processing performance of the entire verification server may not be improved.

  Accordingly, an object of the present invention is to improve the processing performance of a verification server by shortening the time from receiving a verification request to responding a verification result in a verification server using HSM.

In order to solve the above problems, according to one embodiment of the present invention, a plurality of cryptographic modules such as HSM are provided in a verification server, and cryptographic computation is performed using a cryptographic module that is least loaded.
For example, the present invention is a verification server that performs certificate verification processing, and includes a plurality of cryptographic modules that perform cryptographic operations included in the verification processing, and a control unit, and the control unit includes the cryptographic module And a process of selecting the cryptographic module with the lightest load condition and performing the cryptographic operation.

In order to solve the above problems, another aspect of the present invention provides a software encryption module of the verification server and an HSM, respectively, when the processing performance of the verification server is clearly better than that of the HSM. , To perform a specific process.
For example, the present invention is a verification server that accepts a certificate verification request, constructs an authentication path, and verifies the authentication path with a verification server connected to the HSM, and stores a software cryptographic module In the certification path verification process, in the signature verification process of the certificate, certificate revocation list, or OCSP response, the hash value of the certificate, certificate revocation list, or OCSP response is calculated using the software cryptographic module. The signature verification process is performed by decrypting the signature value of the certificate to be certified, the certificate revocation list, or the OCSP response using the software cryptographic module, and comparing the calculated hash value with the decrypted data. And using the software cryptographic module, the hash value of the signature verification result is Calculated by the hash value of the signature verification result, and encrypted using the private key of the HSM and within the HSM, and having a control unit for generating a signature value.

  As described above, according to the present invention, in the verification server using the HSM, it is possible to shorten the time from receiving the verification request to responding the verification result, and to improve the processing performance of the verification server.

Schematic of a verification system. Schematic of a verification server. Schematic diagram of a cryptographic module list table. Schematic of a corresponding encryption algorithm table. Schematic of a load state table. Schematic diagram of a computer. The flowchart which shows the process which monitors the load state of an encryption module. The flowchart which shows the verification process of the certificate in a verification server. The flowchart which shows the signature verification process of a certificate, a CRL, or an OCSP response. The flowchart which shows the production | generation process of the electronic signature by the private key of a verification server.

  FIG. 1 is a schematic diagram of a verification system 100 according to an embodiment of the present invention.

  As illustrated, the verification system 100 includes a terminal device 110, a CA device 120, a verification server 130, and an HSM 150 so that these can exchange information with each other via a network 160. Has been.

  The terminal device 110 communicates with other devices via the network 160, and in particular, transmits and receives a signed electronic document.

  When the terminal device 110 receives the signed electronic document and certificate from another device, the terminal device 110 verifies the signature of the signed electronic document using the received certificate at the same time.

  Further, the terminal device 110 transmits a verification request to the verification server 130 in order to verify the certificate used for signature verification of the signed electronic document. A CA certificate trusted by the user who is the operator of the terminal device 110 and a certificate to be verified are attached to the verification request.

  When the terminal device 110 receives a verification result that the verification target certificate is valid from the verification server 130, the verification target certificate is valid and the signed electronic document is valid. If necessary, the signature of the signed electronic document and the verification result of the certificate are output from the output unit.

  When the CA device 120 receives a certificate issuance request via the network 160, the CA device 120 creates a certificate for the request and sends it back by mail or communication. At this time, the certificate is signed with the private key of the CA device 120.

  The CA device 120 registers the created certificate in the certificate database, and registers and manages the information of the issue destination (that is, the issue request source) in the issue destination management list.

  When the CA device 120 receives a certificate revocation request via the network 160, the CA device 120 deletes the certificate to be revoked from the certificate database and stores the issue destination information of the certificate in the issue destination management list. Delete from.

  Then, the CA device 120 periodically creates and stores a revocation certificate list (CRL) that describes the serial number of the certificate deleted from the certificate database in response to the revocation request. In the created CRL, among the certificates issued by the CA device 120, the serial number of the certificate that has been revoked despite the expiration date, the date and time that the certificate has expired, and the certificate that has been revoked The reasons why are described as a list. Further, the next scheduled CRL creation time is described, and a signature is given using the secret key of the CA device 120.

  When the CA device 120 receives a CRL acquisition request from another device via the network 160, the CA device 120 transmits the stored CRL to the other device that has made an inquiry via the network 160.

  The method of providing the certificate revocation information by the CA device 120 is not limited to the example of issuing a CRL. For example, an OCSP responder may be prepared to provide the certificate revocation information.

  Moreover, there is no limitation in particular about the number of the terminal devices 110 described above and the CA device 120.

  FIG. 2 is a schematic diagram of the verification server 130.

  As illustrated, the verification server 130 includes a storage unit 131, a control unit 136, an input unit 145, an output unit 146, a communication unit 147, and an I / F unit 148.

  The storage unit 131 includes a setting information storage area 132, a certificate storage area 133, and a key management information storage area 134.

  In the setting information storage area 132, information for specifying a cryptographic module that can be used by the verification server 130, information for specifying a cryptographic algorithm corresponding to a cryptographic module that can be used by the verification server 130, and information that can be used by the verification server 130 Information for specifying the load state of the cryptographic module and setting information necessary for the verification server 130 to provide a verification service are stored.

  Specifically, in the setting information storage area 132, an encryption module list table 170 as shown in FIG. 3 (schematic diagram of the cryptographic module list table 170) and FIG. 4 (schematic diagram of the corresponding cryptographic algorithm table 171) are shown. A corresponding encryption algorithm table 171 and a load state table 172 shown in FIG. 5 (schematic diagram of the load state table 172) are stored.

  The cryptographic module list table 170 illustrated in FIG. 3 includes a cryptographic module identifier field 170a, a setting information field 170b, and a key management flag field 170c.

  The cryptographic module identifier field 170a stores a cryptographic module identifier that is identification information for identifying the cryptographic module.

  In the present embodiment, hardware and software capable of performing cryptographic operation processing are referred to as “cryptographic modules”. Here, the first software cryptographic module 142, the second software cryptographic module 143, and the HSM 150 provided in the control unit 136 of the verification server 136 correspond to the “cryptographic module”, and each identifier is designated as “first software. “Cryptographic module”, “second software cryptographic module”, and “HSM” are stored in this column.

  The setting information column 170b stores setting information necessary for the verification server 130 to perform cryptographic processing with the cryptographic module specified in the cryptographic module identifier column 170a.

  The key management flag column 170c stores information for specifying whether or not the cryptographic module specified in the cryptographic module identifier column 170a has the secret key of the verification server 130. Here, in the present embodiment, when the character string “Yes” is stored in this column, the secret key of the verification server 130 is assumed, but the present invention is not limited to this mode.

  The cryptographic module list table 170 is created in advance by the operator of the verification server 130 via the input unit 145 and stored in the setting information storage area 132.

  The correspondence encryption algorithm table 171 shown in FIG. 4 has an encryption algorithm area 171a and a correspondence specifying area 171d.

  The cryptographic algorithm area 171a includes a hash algorithm area 171b and a public key algorithm area 171c, and each row of the hash algorithm area 171b includes information for specifying a hash algorithm, and each line of the public key algorithm area 171c includes Information identifying the public key algorithm is stored.

  Each column of the correspondence specifying area 171d stores information for specifying the cryptographic module.

  In the column where the algorithm specified in each row of the encryption algorithm area 171a and the encryption module specified in each column of the corresponding specification area 171d intersect, whether or not the encryption module corresponds to the algorithm Information for identifying is stored. In the present embodiment, when a symbol “◯” is stored in these intersecting fields, it indicates that the cryptographic module is compatible with the algorithm, and a symbol “x” is stored. If it is, it is shown that the cryptographic module does not support the algorithm, but the present invention is not limited to such a mode.

  The load state table 172 illustrated in FIG. 5 includes a cryptographic module identifier field 172a and a load state field 172b.

  The cryptographic module identifier field 172a stores a cryptographic module identifier that is identification information for identifying the cryptographic module.

  The load status column 172b stores information for specifying the load status of the cryptographic module specified in the cryptographic module identifier column 172a.

  Returning to FIG. 2, the certificate storage area 133 stores the certificate of the verification server 130.

  In the key management information storage area 134, management information for managing the secret key of the verification server 130 (for example, information specifying the label of the secret key stored in the HSM 150) is stored.

  The control unit 136 includes an overall control unit 137, a certificate verification unit 138, a verification result creation unit 139, a cryptographic module selection unit 140, a cryptographic module monitoring unit 141, a first software cryptographic module 142, and a second Software encryption module 143.

  The overall control unit 137 controls overall processing in the verification server 130.

  In response to the verification request from the terminal device 110, the certificate verification unit 138 performs processing for building a certification path to the verification target certificate using the CA certificate attached to the verification request as a trust point.

  In addition, the certificate verification unit 138 performs processing for verifying the constructed certification path.

  The verification result creation unit 139 performs processing for creating a verification result message according to the verification result of the verification target certificate executed by the certificate verification unit 138.

  The cryptographic module selection unit 140 is executed when the certificate verification unit 138 performs a certificate or CRL signature verification process performed in the process of verifying the certification path, or when the verification result creation unit 139 creates a verification result message. A process of selecting a cryptographic module for executing the signature process is performed.

  The cryptographic module monitoring unit 141 identifies a cryptographic module that can be used by the verification server 130 from the cryptographic module list table 170 at a predetermined timing (for example, a timing at which a service of the verification server 130 is started). All the modules are accessed, the cryptographic algorithms that can be supported by the respective cryptographic modules are investigated, the corresponding cryptographic algorithm table 171 is created, and the setting information storage area 132 is stored. This process may be performed based on PKCS (Public Key Cryptography Standards) # 11.

  In addition, the cryptographic module monitoring unit 141 performs processing for specifying a cryptographic module that can be used by the verification server 130 in the cryptographic module list table 170, monitoring the load state of the identified cryptographic module, and storing it in the load state table 172. .

  Each of the first software cryptographic module 142 and the second software cryptographic module 143 performs encryption such as a certificate verification process of a certificate or a certificate revocation list in a certification path verification process and a signature generation process of a verification server for a verification result. Perform the operation.

  The input unit 145 receives information input.

  The output unit 146 outputs information.

  The communication unit 147 transmits and receives information via the network 160.

  The I / F unit 148 transmits and receives information to and from the HSM 150.

  The verification server 130 described above includes, for example, a CPU (Central Processing Unit) 181, a memory 182, and an external storage device 183 such as an HDD (Hard Disk Drive) as shown in FIG. 6 (schematic diagram of the computer 180). A reading device 185 for reading / writing information from / to a portable storage medium 184 such as a CD-ROM (Compact Disk Read Only Memory) or a DVD-ROM (Digital Versatile Disk Read Only Memory), a keyboard, a mouse, etc. An input device 186, an output device 187 such as a display, a communication device 188 such as a NIC (Network Interface Card) for connection to a communication network, an I / F (interface) 189 such as a USB (Universal Serial Bus), It is realizable with the general computer 180 provided with.

  For example, the storage unit 131 can be realized by the CPU 181 using the memory 182 or the external storage device 183, and the control unit 136 loads a predetermined program stored in the external storage device 183 into the memory 182. The input unit 145 can be realized by using the input device 186 by the CPU 181, and the output unit 146 can be realized by using the output device 187 by the CPU 181. The communication unit 147 can be realized by the CPU 181 using the communication device 188, and the I / F unit 148 can be realized by the CPU 181 using the I / F 189.

  The predetermined program is downloaded from the storage medium 184 via the reading device 185 or from the network via the communication device 188 to the external storage device 183, and then loaded onto the memory 182 and executed by the CPU 181. You may do it. Alternatively, the program may be directly loaded on the memory 182 from the storage medium 184 via the reading device 185 or from the network via the communication device 188 and executed by the CPU 181.

  The HSM 150 only needs to use at least one corresponding to PKCS # 11 and may be a general-purpose one, and detailed description thereof is omitted.

  The HSM 150 is connected to the verification server 130 directly or via a network. In the present embodiment, as shown in FIG. 1, the HSM 150 is directly connected to the verification server 130. However, the HSM 150 is limited to such an aspect. Not.

  In FIG. 1, the HSM 150 and the verification server 130 are connected on a one-to-one basis, but may be connected on a one-to-many, many-to-many, or many-to-one basis.

  FIG. 7 is a flowchart showing processing for monitoring the load state of the cryptographic module in the verification server 130.

  First, when a predetermined monitoring interval, for example, several tens of seconds has elapsed (Yes in S10), the cryptographic module monitoring unit 141 identifies the cryptographic module specified in the cryptographic module identifier field 170a of the cryptographic module list table 170. Among them, one unexamined cryptographic module is selected (S11), and setting information for using the selected cryptographic module is acquired from the setting information column 170b (S12).

  Then, the cryptographic module monitoring unit 141 performs a dummy cryptographic operation on the cryptographic module selected in step S11 (S13). Here, the dummy cryptographic operation is performed using, for example, the same data in the cryptographic algorithm corresponding to all the cryptographic modules stored in the cryptographic module list table 170a (for example, the hash for the test data) Calculation).

  Next, the cryptographic module monitoring unit 141 displays the time taken for the cryptographic calculation performed in step S13 (for example, the time from when the calculation instruction is output to the cryptographic module until the calculation result response is received) in the load state. The table 172 is stored in association with the cryptographic module for which the cryptographic operation has been performed in step S13 (S14).

  Then, the cryptographic module monitoring unit 141 determines whether or not the processing of steps S12 to S14 has been performed for all the cryptographic modules stored in the cryptographic module list table 170 (S15). (Yes in step S15), the process returns to step S11 and the process is repeated. If all the cryptographic modules have been investigated (No in step S15), the process returns to step S10 and the process is repeated.

  FIG. 8 is a flowchart showing certificate verification processing in the verification server 130.

  When receiving a certificate verification request from the terminal device 110 via the communication unit 147 (Yes in S20), the overall control unit 137 of the verification server 130 passes the verification request to the certificate verification unit 138.

  Then, the certificate verification unit 138 acquires the CA certificate of the CA device 120 trusted by the user of the terminal device 110 and the verification target certificate that is the verification target from the passed verification request (S21). A certification path from the acquired CA certificate to the acquired verification target certificate is constructed (S22).

  Next, the certificate verification unit 138 verifies the constructed certification path after the certification path is constructed (S23).

  Specifically, the certificate verification unit 138, for all the certificates excluding the CA certificate of the trusted CA that is the starting point of the path, out of the plurality of certificates that constitute the certification path constructed in step S22, The signature attached to the certificate is verified using the public key described in the CA certificate of the CA device 120 that issued each certificate.

  In addition, the certificate verification unit 138 confirms the CRL issued by the CA device 120 that issued the certificate and inquires the OCSP responder to confirm that the certificate has not been revoked for all the certificates. To confirm.

  Then, the certificate verification unit 138 verifies the signature of the issuing CA device 120 attached to the CRL or OCSP response using the public key described in the certificate of the issuing CA device 120. In addition to the confirmation of these items, the items specified in Chapter 6 “Authentication Path Verification” of RFC5280 are also confirmed.

  Next, the verification result creation unit 139 creates a message that describes the result of verification of the authentication path in step S23, generates a signature value for the message using the secret key of the verification server 130, and A verification result message is created by attaching the signature value and the certificate of the verification server 130 to the created message (S24).

  Then, the overall control unit 137 of the verification server 130 transmits the verification result message created in step S24 to the terminal device 110 that has transmitted the verification request in step S20 (S25), and returns to step S20 for processing. repeat.

  FIG. 9 is a flowchart showing a signature verification process of a certificate, CRL, or OCSP response in the certification path verification process of step S23 of FIG.

  First, the certificate verification unit 138 acquires a hash algorithm and a public key encryption algorithm related to a signature value from a certificate for signature verification, a CRL, or an OCSP response (S30).

  Next, the certificate verification unit 138 uses the cryptographic module selection unit 140 to search the corresponding cryptographic algorithm table 171 using the hash algorithm acquired in step S30 as a key, thereby corresponding to the hash algorithm used as a key. Whether there is a cryptographic module is searched (S31).

  If there is no cryptographic module corresponding to the hash algorithm used as the key (No in step S31), the certificate verification unit 138 proceeds to step S45, and if there is a corresponding cryptographic module (Yes in step S31). ), Go to step S32.

  In step S32, the certificate verification unit 138 determines whether there are a plurality of cryptographic modules corresponding to the hash algorithm used as a key. If there is not a plurality of cryptographic modules corresponding to the hash algorithm used as a key (No in step S32), the process proceeds to step S33. If there are a plurality of cryptographic modules (Yes in step S32), the process proceeds to step S34.

  In step S33, the cryptographic module selection unit 140 selects only the cryptographic module corresponding to the hash algorithm used as the key, and proceeds to step S36.

  On the other hand, in step S34, the cryptographic module selection unit 140 acquires all cryptographic module identifiers corresponding to the hash algorithm as a key from the corresponding cryptographic algorithm table 171 (S34).

  Next, the cryptographic module selection unit 140 searches the load state table 172 using all the cryptographic module identifiers acquired in step S34 as a key, and among the cryptographic modules corresponding to the cryptographic module identifier used as the key, the highest load is obtained. A cryptographic module that is not applied is selected (S35). Here, in the present embodiment, among the corresponding cryptographic modules, the module having the shortest time stored in the load status column 172b of the load status table 172 is selected. When there are a plurality of the shortest times, one cryptographic module is specified according to a predetermined rule such as giving priority to the HSM 150.

  In step S36, the certificate verification unit 138 performs hash calculation for signature verification using the cryptographic module selected by the cryptographic module selection unit 140 (S36). Specifically, a hash calculation using the hash algorithm obtained in step S30 is performed on the verification target certificate, the electronic signature of the signature target part of the CRL or OCSP response using the selected cryptographic module, and the result is obtained. The hash value is obtained by combining the value with the identifier (OID) of the hash algorithm.

  Next, the certificate verification unit 138 searches the corresponding encryption algorithm table 171 using the public key encryption algorithm acquired in step S37 as a key, and determines whether there is an encryption module corresponding to the public key encryption algorithm used as the key. Search is performed (S37).

  Then, if there is no encryption module corresponding to the public key encryption algorithm used as the key (No in step S37), the certificate verification unit 138 proceeds to step S45, and if there is a corresponding encryption module (step S37). Yes), the process proceeds to step S38.

  In step S38, the certificate verification unit 138 determines whether there are a plurality of cryptographic modules corresponding to the public key cryptographic algorithm used as a key. If there are not a plurality of cryptographic modules corresponding to the public key cryptographic algorithm used as a key (No in step S38), the process proceeds to step S39. If there are a plurality of cryptographic modules (Yes in step S38), the process proceeds to step S40.

  In step S39, the cryptographic module selection unit 140 selects only the cryptographic module corresponding to the public key cryptographic algorithm used as a key, and proceeds to step S42.

  In step S <b> 40, the cryptographic module selection unit 140 acquires all cryptographic module identifiers corresponding to the public key cryptographic algorithm as a key from the corresponding cryptographic algorithm table 171.

  Next, the cryptographic module selection unit 140 searches the load state table 172 using all the cryptographic module identifiers acquired in step S40 as keys, and the highest load among the cryptographic modules corresponding to the cryptographic module identifiers used as keys. A cryptographic module which is not applied is selected (S41). Here, in the present embodiment, among the corresponding cryptographic modules, the module having the shortest time stored in the load status column 172b of the load status table 172 is selected. When there are a plurality of the shortest times, one cryptographic module is specified according to a predetermined rule such as giving priority to the HSM 150.

  Then, the certificate verification unit 138 uses the selected cryptographic module to decrypt the signature value to be verified, and confirms that the decrypted decrypted data and the hash value acquired in step S36 are the same. Then, signature verification processing is performed (S42). Specifically, in the selected cryptographic module, the public key cryptographic algorithm acquired in step S30, the public key described in the CA certificate of the CA device 120 that issued the verification target certificate, the CRL or the OCSP response, The signature is verified using the verification target certificate, the signature value of the CRL or OCSP response, and the hash value acquired in step S36 as input values. That is, the selected cryptographic module decrypts the input signature value using the input public key with the input public key encryption algorithm, and the resulting decrypted data and the input hash value If they are the same, a response that the signature verification is successful is returned, and if they are different, a response that the signature verification failed is returned to the certificate verification unit 138.

  Next, the certificate verification unit 138 receives the signature verification result from the selected cryptographic module, and if the received verification result is successful (Yes in S43), the signature of the verification target certificate is valid. (S44), and the certification path verification process is continued.

  On the other hand, if the received verification result is unsuccessful (No in step S43), the certificate verification unit 138 proceeds to step S45.

  In step S45, the certificate verification unit 138 determines that the signature of the verification target certificate is not valid, and determines that the certification path verification processing has failed.

  FIG. 10 is a flowchart showing a digital signature generation process using the secret key of the verification server 130.

  The verification result creation unit 139 uses the secret key information of the verification server 130 set by the operator of the verification server 130 to determine a hash algorithm and a public key encryption algorithm that the verification server 130 uses when generating a signature for the verification result message. Obtain (S50). These pieces of information are assumed to be stored in the key management information storage area 134.

  Next, the verification result creation unit 139 uses the cryptographic module selection unit 140 to set a plurality of cryptographic modules corresponding to the keyed hash algorithm from the corresponding cryptographic algorithm table 171 using the hash algorithm acquired in step S50 as a key. It is confirmed whether or not there is (S51).

  If there is not a plurality of cryptographic modules corresponding to the hash algorithm used as a key (No in step S51), the process proceeds to step S52. If there are a plurality of cryptographic modules (Yes in step S51), the process proceeds to step S53.

  In step S52, since there is only one cryptographic module corresponding to the hash algorithm used as the key, the cryptographic module selection unit 140 selects the cryptographic module and proceeds to step S55.

  On the other hand, in step S <b> 53, the cryptographic module selection unit 140 acquires all cryptographic module identifiers corresponding to the hash algorithm as a key from the corresponding cryptographic algorithm table 171.

  Next, the cryptographic module selection unit 140 searches the load state table 172 using all the cryptographic module identifiers acquired in step S53 as keys, and the highest load among the cryptographic modules corresponding to the cryptographic module identifiers used as the keys. A cryptographic module which is not applied is selected (S54). Here, in the present embodiment, among the corresponding cryptographic modules, the module having the shortest time stored in the load status column 172b of the load status table 172 is selected. When there are a plurality of the shortest times, one cryptographic module is specified according to a predetermined rule such as giving priority to the HSM 150.

  In step S55, the verification result creation unit 139 performs hash calculation for signature generation using the selected cryptographic module. Specifically, the verification result message to be signed is input to the selected cryptographic module, hash calculation is performed using the hash algorithm acquired in step S50, and the hash algorithm is specified in the resulting value. Together with the identifier (OID), a hash value is obtained.

  Next, the verification result creation unit 139 searches the cryptographic module list table 170, searches for the cryptographic module in which the character string “Yes” is stored in the key management flag column 170c, and acquires the identifier of the searched cryptographic module. (S56).

  Then, the verification result creating unit 139 encrypts the hash value calculated in step S55 using the secret key of the verification server 130 in the cryptographic module corresponding to the cryptographic module identifier acquired in step S56 (S57). Specifically, the public key encryption algorithm acquired in step S50, information for specifying the secret key of the verification server 130, and the hash value acquired in step S55 are used as input values, and the encryption acquired in step S56. Input to the module, and the hash value input in the encryption module is encrypted using the secret key corresponding to the information for specifying the input secret key.

  Then, the cryptographic module outputs the signature value obtained in step S57 to the verification result creation unit 139 (S58). Upon receiving this, the verification result creating unit 139 attaches the signature value and the certificate of the verification server 130 corresponding to the private key stored in the key management information storage area 134 to the message indicating the verification result. Get a telegram.

  In step S56, when there are a plurality of cryptographic modules in which the character string “Yes” is stored in the key management flag field 170c, that is, when there are a plurality of cryptographic modules that manage the secret key of the verification server 130. May select the cryptographic module with the least load among the cryptographic modules having such a secret key, and perform the encryption processing in step S57.

  As described above, according to the present embodiment, even when the verification server 130 receives an enormous number of verification requests from a large number of terminal devices 110, both the HSM 150 and the verification server 130 perform cryptographic operations efficiently. The processing performance of the entire verification server 130 can be improved, and the time from receiving the verification request to transmitting the verification result can be shortened.

  In addition, by managing the algorithms that can be supported by the HSM 150 and the software cryptographic modules 142 and 143 as the corresponding cryptographic algorithm table 171, even when performing cryptographic operations using cryptographic algorithms not supported by any cryptographic module, Therefore, it is not necessary to be aware of which cryptographic module is used by the administrator of the verification server 130, and the operational load can be reduced.

  The present invention is not limited to the embodiments described above, and various modifications can be made within the scope of the gist.

  For example, in the embodiment described above, as a method for the cryptographic module monitoring unit 141 of the verification server 130 to monitor the load state of the cryptographic module, the cryptographic calculation is performed in each cryptographic module at a specific interval, and the cryptographic calculation is performed. Time is being measured. On the other hand, for example, the cryptographic module monitoring unit 141 detects the CPU usage rate of the verification server 130 and the HSM 150 at specific intervals, and stores the detected CPU usage rate in the load status column 172b of the load status table 172. You may do it. In such a case, the CPU with the lowest CPU utilization rate may be used for actual cryptographic computation as the least loaded one.

  Also, the cryptographic module monitoring unit 141 does not monitor each cryptographic module at a specific interval, but each cryptographic module performs processing for generating a hash value in the signature verification processing. The load state may be managed by storing it in the load state column 172b of the table 172. In this case, basically, by setting all the cryptographic modules to be used in order, the processing time in all the cryptographic modules is investigated, and if the processing time takes more than a certain time, the time It is only necessary to use other cryptographic modules instead of using cryptographic modules.

  Furthermore, if the processing performance of the verification server 130 is clearly better than the processing performance of the HSM 150, the cryptographic module selection unit 140 is not used to select a cryptographic module every time a verification request is received, but authentication is always performed. The hash calculation in the signature verification process in the path verification process and the signature value generation process in the verification result message is performed using the software encryption modules 142 and 143 in the verification server 130. In the HSM 150, the signature generation in the verification result message is performed. Only the public key encryption process in may be performed.

100 verification system 110 terminal device 120 CA device 130 verification server 131 storage unit 132 setting information storage region 133 certificate storage region 134 key management information storage region 136 control unit 137 overall control unit 138 certificate verification unit 139 verification result creation unit 140 encryption Module selection unit 141 Cryptographic module monitoring unit 142 First software cryptographic module 143 Second software cryptographic module 150 HSM

Claims (3)

A verification server connected to an HSM (Hardware Security Module), accepting a certificate verification request, constructing an authentication path, and verifying the authentication path,
A storage unit for storing the software cryptographic module;
In the signature verification process of the certificate, certificate revocation list or OCSP response in the certification path verification process,
Using the software cryptographic module, calculate the hash value of the certificate, certificate revocation list or OCSP response,
Using the software cryptographic module, decrypt the certificate to be certified, the certificate revocation list or the signature value of the OCSP response,
The signature verification process is performed by comparing the calculated hash value and the decrypted data,
Using the software cryptographic module, calculating a hash value of the signature verification result,
A controller that encrypts a hash value of the signature verification result using the HSM and a secret key in the HSM, and generates a signature value;
A verification server characterized by that. A verification method in a verification server that accepts a certificate verification request, constructs an authentication path, and verifies the authentication path with a verification server connected to an HSM (Hardware Security Module),
The verification server includes a storage unit that stores a software cryptographic module;
By the verification server,
In the signature verification process of the certificate, certificate revocation list or OCSP response in the certification path verification process,
Using the software cryptographic module, calculate the hash value of the certificate, certificate revocation list or OCSP response,
Using the software cryptographic module, decrypt the certificate to be certified, the certificate revocation list or the signature value of the OCSP response,
The signature verification process is performed by comparing the calculated hash value and the decrypted data,
Using the software cryptographic module, calculating a hash value of the signature verification result,
The hash value of the signature verification result is encrypted using the HSM and a secret key in the HSM, and a process for generating a signature value is performed.
A verification method characterized by that. A verification program for causing a computer connected to an HSM (Hardware Security Module) to receive a certificate verification request, construct a certification path, and verify the certification path,
The computer includes a storage unit that stores a software cryptographic module,
In the computer,
In the signature verification process of the certificate, certificate revocation list or OCSP response in the certification path verification process,
Using the software cryptographic module, calculate the hash value of the certificate, certificate revocation list or OCSP response,
Using the software cryptographic module, decrypt the certificate to be certified, the certificate revocation list or the signature value of the OCSP response,
The signature verification process is performed by comparing the calculated hash value and the decrypted data,
Using the software cryptographic module, calculating a hash value of the signature verification result,
Encrypting a hash value of the signature verification result using the HSM and a secret key in the HSM, and executing a process of generating a signature value;
A verification program characterized by that.

Images