JP2023134108A - Certificate verification device, certificate verification method, program, and certificate verification system - Google Patents

Abstract

To provide a certificate verification device, a certificate verification method, a program, and a certificate verification system that verify a certificate based on a highly reliable trust anchor even when a plurality of trust lists exist.SOLUTION: In a certificate verification system 1, a certificate verification server 50 acquires, based on information on multiple trust lists (TLs) received from a plurality of TL publishing sites, each of information on linkage relationships between the multiple TLs and validity of the multiple TLs, and information on a certificate authority registered in the TLs whose linkage relationships and validity have been confirmed, and stores them in a memory. When a verification request including a certificate to be verified is received from a plurality of verification requester terminals, the certificate verification server, based on the certificate information of the certification authority identified from the stored information, verifies the linkage relationship between a certification authority indicated by the certificate to be verified and the identified certification authority and the validity of the certificate of each certification authority, and transmits verification results to the verification requester terminals.SELECTED DRAWING: Figure 1

Description

The present invention relates to a certificate verification device, a certificate verification method, a program, and a certificate verification system.

Electronic certificates are becoming widely used for electronic contracts such as electronic applications. Along with this, there are also many certification authorities that manage electronic certificates. Therefore, a model for performing mutual authentication between multiple certificate authorities has been proposed. Typical methods of mutual authentication between certificate authorities include, for example, a bridge model and a trust list (or trusted list).

Compared to mutual authentication using a bridge model, mutual authentication using a trust list has the advantage that the processing load for building a certification relationship between certificate authorities and verifying each certificate (construction and verification of a certification path) is small. be. On the other hand, mutual authentication using trust lists involves processing unique to trust lists, such as building and verifying relationships between trust lists. Furthermore, in the trust list, management of the trust anchor, which is the origin of trust in a certificate (certificate authority), may be more complicated than in the bridge model. In particular, when trust lists are used across multiple countries or regions, the burden of managing or processing them is expected to increase.

In this regard, Non-Patent Documents 1 and 2 disclose a method of performing mutual authentication of certificates among EU member countries in a model using a trust list (TL model).

Furthermore, in Patent Document 1, a trust point certificate management server has a database of public key certificates issued by trust points of information terminals, and when a request for sending a necessary public key certificate is received from an information terminal. discloses that the above database is searched, and when the public key certificate is found as a result of the search, the public key certificate is sent to the information terminal. Further, Patent Document 2 discloses a method of issuing a digital certificate that can be used in multiple encryption systems.

Japanese Patent Application Publication No. 2006-148454 Japanese Patent Application Publication No. 2020-010396

"ETSI TS 119 172-4 V1.1.1", [online], [searched on February 25, 2022], Internet, <URL: https://standards.globalspec.com/std/14387063 /ts-119-172-4＞ "ETSI TS 119 615 V1.1.1", [online], [searched on February 25, 2022], Internet, <URL: https://www.etsi.org/deliver/etsi_ts/119600_119699 /119615/01.01.01_60/ts_119615v010101p.pdf＞

However, Non-Patent Documents 1 and 2 do not consider the case where trust lists are linked with regions other than EU member states.

Further, although the patent document 1 manages certificates in a consolidated manner, it is not possible to confirm the trust relationship between them. Furthermore, Patent Document 2 discloses a method in which a certificate containing multiple cryptographic algorithms and signature values is issued, and the signature is verified using an algorithm that a verifier can handle. Since it cannot be embedded in written information, it cannot be applied when determining the method of a certificate. In addition, when bridge models and trust lists coexist in the market, certificate verifiers cannot simply refer to the certificate to be verified; I can't even judge whether that's the case.

The present invention was made in view of the current situation, and its purpose is to make it possible to verify certificates based on highly reliable trust anchors even when multiple trust lists exist. The purpose of the present invention is to provide a certificate verification device, a certificate verification method, a program, and a certificate verification system.

One of the present inventions for solving the above-mentioned problems is provided with a processor and a memory, and the processor selects between the plurality of trust lists based on information of the plurality of trust lists received from a first information processing device. a trust list that acquires and stores in the memory information on the connection relationship and the validity of the plurality of trust lists, and information on certificate authorities registered in the trust list whose connection relationship and validity have been confirmed; Store management processing that executes the acquisition processing, and when a verification request including a verification target certificate is received from the second information processing device, information on the certificate of the certificate authority specified from the information stored in the memory is stored. A certificate verification common method that executes a trust list verification process that verifies the connection relationship between the certification authority indicated by the certificate to be verified and the identified certification authority, and the validity of the certificate of each certification authority based on the verification target certificate. and a verification result response process of transmitting the verified result to the second information processing device.

According to the present invention, even if a plurality of trust lists exist, a certificate can be verified based on a highly reliable trust anchor.
Structures, effects, etc. other than those described above will be made clear by the description of the embodiments below.

1 is a diagram showing an example of the configuration of a certificate verification system according to the present embodiment. It is a diagram showing an example of the configuration of a bridge model and a TL model in the certificate verification system of the present embodiment. FIG. 3 is a diagram showing an example of a data structure of a TL. FIG. 3 is a diagram showing an example of a TL management table. FIG. 3 is a diagram showing an example of a TL path management table. It is a figure showing an example of a TSP management table. FIG. 3 is a diagram showing an example of a certificate management table. It is a figure which shows an example of update setting value information. FIG. 2 is a diagram illustrating an example of hardware included in each information processing device in the certificate verification system. FIG. 2 is a diagram illustrating an overview of processing performed in the certificate verification system. It is a flow diagram explaining an example of TL acquisition processing. FIG. 3 is a flow diagram illustrating details of TL path construction verification processing. FIG. 3 is a flow diagram illustrating an example of certificate verification processing. FIG. 3 is a diagram illustrating an example of a data format of an OCSP request. FIG. 3 is a diagram illustrating an example of a data format of an OCSP response. FIG. 7 is a diagram illustrating details of additional processing. FIG. 3 is a flow diagram illustrating processing related to the construction of a certification path among the construction and verification processing. FIG. 2 is a flow diagram illustrating processing related to certification path verification (certificate validity verification) among the construction and verification processing.

FIG. 1 is a diagram showing an example of the configuration of a certificate verification system 1 according to the present embodiment. The certificate verification system 1 includes a plurality of verification requester terminals 10 (10a, . . . ) used by users who send and receive data such as electronic documents attached with electronic certificates issued by a certification authority (hereinafter simply referred to as certificates). , 10n) (second information processing device) and one or more certification authority servers 20 (30a,..., 30n) managed by the certification authority that issues the certificate. A plurality of TL public sites 30 (30a, . . . ., 30n) (first information processing device), and multiple TL signature certificate publishing sites 40 (40a,..., 40n) that publish public key certificates for verifying TLs. , a certificate verification server 50 (certificate verification device) to be described later.

For example, the connection between the verification requester terminal 10, the certificate authority server 20, the TL public site 30, the TL signature certificate public site 40, and the certificate verification server 50 is the Internet, LAN (Local Area Network), or WAN (Wide Area Network). Communication is possible via a wired or wireless communication network 5 such as a network) or a dedicated line.

The certificate verification system 1 uses the TL, which is a list of certificate authorities trusted by administrators in each country or region, and the bridge model, which is a network of mutual authentication certificates exchanged between two certificate authorities, to verify each certificate. The reliability of the certification authorities (the connectivity between the certification authorities and the validity of each certification authority's certificate) is ensured.

FIG. 2 is a diagram showing an example of the configuration of a bridge model and a TL model (hereinafter referred to as TL model) in the certificate verification system 1 of this embodiment.

First, in the bridge model 500, mutual authentication between certificate authority CA1 and certificate authority BCA, between certificate authority BCA and certificate authority CA2, and between certificate authority CA2 and certificate authority CA3 uses mutual authentication certificate 501. This is done by exchanging each other. A mutual authentication certificate issued by a partner certification authority to its own certification authority and a mutual authentication certificate issued by its own certification authority to its partner certification authority in the form of a pair is called a mutual authentication certificate pair. The mutually authenticated certificate pair is published on the directory server. Note that the certificate authority CA3 directly manages the subordinate certificate authority CA3a and certificate authority CA3b. Further, each certification authority (including lower-level certification authorities) issues an EE certificate 503 (EE: End Entity) to the user (EE).

The TL model 600 manages certificate authorities in one or more countries or regions. In other words, the TL model 600 includes a first TL 610 in which at least information on the certificate authority CA2 and certificate authority CA3b in the bridge model 500 and information on the certificate authority CA4 not covered by the bridge model 500 is registered, and one or more countries in the region. , and a third TL 630 that stores information on certificate authorities CA5 and CA6 of each country in the region. Each TL identifies other TLs by pointers 640. Each certificate authority issues an EE certificate 650 to a user (EE).
Here, the data structure of the TL will be explained.

(TL)
FIG. 3 is a diagram showing an example in which a part of the data structure of the TL is extracted. Each TL 300 includes a pointer 301 to another TL and a signature 304. A pointer 301 indicates a combination consisting of a public key certificate 302 for verifying the own TL or another TL that has a trust relationship with the own TL, and the location 303 (URL in this embodiment) of the other TL. , one or more.

In the example in the figure, the origin "TL C1" specifies "TL A1" by the location 303, and the public key extracted from the public key certificate 302 related to "TL A1" of "TL C1" specifies "TL A1". ” signature 304 is verified. “TL A1” is “TL A1” according to the location 303.
C1", "TL C2", and "TL C3", and use the public keys extracted from the public key certificates related to "TL C1", "TL C2", and "TL C3" of "TL A1" to identify "TL C1". ”, “TL C2”, and “TL C3” are verified.

Next, as shown in FIG. 1, the certificate verification server 50 includes a verification request reception section 51, a verification result response section 52, a certificate verification common processing section 53, a TL method verification addition processing section 54, and a store management section 57. It is equipped with each functional section (program).

The verification request receiving unit 51 receives a verification request including a certificate to be verified from the verification requester terminal 10 .

The verification result response unit 52 transmits a verification response, which is response data, to the verification requester terminal 10 in response to the verification request.

Based on the information on the plurality of trust lists received from the TL public site 30, the store management section 57 stores information on the connection relationship between the plurality of trust lists and the validity of the plurality of trust lists (construction of TL path and verification thereof). ) and the information on the certificate of the certificate authority registered in the trust list whose connection relationship and validity have been confirmed are respectively acquired and stored in the TL management store 200 and the certificate store 100.

Note that the store management section 57 includes a certificate store management section 55 and a TL store management section 56. The certificate store management unit 55 analyzes certificates of certificate authorities and performs processing related to information management related to certificates. The TL store management unit 56 performs processing related to trust list validity and connectivity (TL signature verification, path construction between TLs, etc.).

When the certificate verification common processing unit 53 receives a verification request including a certificate to be verified from the verification requester terminal 10, the certificate verification common processing unit 53 specifies the certificate from the TL management store 200 and the certificate store 100 stored in the store management unit 57. Based on the certificate information of the certificate authority, a trust list verification process is performed to verify the connection relationship between the certificate authority indicated by the certificate to be verified and the certificate authority specified above, and the validity of each certificate authority's certificate. Execute.

In this embodiment, if the verification request does not include a bridge model trust anchor, the certificate verification common processing unit 53 issues a certificate of the certificate authority registered in the certificate store 100 (certificate verification server 50 executes the trust list verification process based on the information of the trans anchor set independently.

The TL method verification addition processing unit 54 creates information indicating the quality of the trust list related to the certification authority that constructed and verified the certification path during the trust list verification process, based on the TL management store 200.

The certificate verification server 50 also stores a certificate store 100, a TL management store 200, and update setting value information 270 databases.

The TL management store 200 stores a TL management table 210, a TL path management table 230, and a TSP management table 250.

(TL management table)
FIG. 4 is a diagram showing an example of the TL management table 210. The TL management table 210 is a database that centrally manages TL information.

The TL management table 210 includes a country name 211 where the name of the country or region that manages the TL (hereinafter referred to as TL management country) is set, a TL scheme name 212 where the name of the scheme of the TL is set, and the date and time of issue of the TL. The publication date and time 213 where the next update date and time of the TL is set, the next update date and time 214 where the next update date and time of the TL is set, the distribution point 215 where the distribution point of the TL is set, and information on each other TL pointed to by the TL. The list has a pointer 216 for each data item to be set.

The pointer 216 has sub-items of a TL location 217 in which location information (URL in this embodiment) of each TL is set, and a certificate 218 in which information indicating the public key certificate of each TL is set. Note that in this embodiment, the public key certificate is X. 509 certificate, but the format is not particularly limited.

(TL path management table)
FIG. 5 is a diagram showing an example of the TL path management table 230. The TL path management table 230 is a table that stores patterns of paths between TLs (hereinafter referred to as TL paths) made up of a plurality of TLs.

The TL path management table 230 includes a starting point 231 where the starting point of the TL path is set, an ending point 232 where the ending point of the TL path is set, a TL path (scheme name) 233 where information specifying the TL path by scheme name is set, It also has each data item of TL path (URL) 234 in which information specifying the TL path using location information (URL in this embodiment) is set.

(TSP management table)
FIG. 6 is a diagram showing an example of the TSP management table 250. The TSP management table 250 is a database in which information (hereinafter referred to as TSP information) regarding business operators (certified authorities in this embodiment) registered in the TL is stored.

The TSP management table 250 includes a country name 251 in which the TL management country of the TL in which the certificate authority is registered is set, a service type identifier 252 in which the identifier of the service provided by the certificate authority is set, and a name of the service of the certificate authority. A service name 253 where a certificate is set, a status 254 where information indicating whether or not the public key certificate of the certificate authority is valid is set, and a certificate of the certificate authority (hereinafter also referred to as a CA certificate. CA: Certificate Authority). Service information extension 255 in which information regarding the quality of the certificate (e.g., determination of a Qualified Certificate (QC), Qualified Signature Create Device (QSCD)) is set, and publication of the certificate authority. It has each data item of the certificate 256 in which information specifying the key certificate is set. In the service information extension 255, information is set, for example, such as the degree of quality of certification, whether usage such as signature is set, and whether the private key is managed by hardware.

The certificate store 100 stores a certificate management table 110.
(Certificate management table)
FIG. 7 is a diagram showing an example of the certificate management table 110. The certificate management table 110 is a database that manages detailed information on public key certificates. The certificate management table 110 includes an issuer name 111 where information on the issuer of the public key certificate (country name, organization name, etc.) is set, and an issuer key identifier 112 where information on the public key issued by the issuer is set. , a subject name 113 in which information on the subject to be certified by the certificate (country name, organization name, etc.) is set; a subject key identifier 114 in which information on the public key of the subject to be certified is set; Serial number 115 where the serial number of the certificate is set, Trust model 116 where information indicating the certificate verification method (model type) supported by the public key certificate is set, and the public key certificate is set in the TL. It has data items such as TL publication presence/absence 117, in which a flag indicating whether the public key certificate is registered or not is set, and country name 118, in which the TL management country is set when the public key certificate is registered in the TL.

Note that in this embodiment, the trust model 116 is set to either a bridge model, a TL model, or both models. Further, it is assumed that the trust model 116 is set in advance by the user (for example, the certificate verification server 50 displays an input screen and accepts input from the user).

(Update setting value information)
FIG. 8 is a diagram illustrating an example of updated setting value information 270. The update setting value information 270 is information that presets the timing at which the certificate verification server 50 acquires and updates information regarding the TL.

The update setting value information 270 is information including an identifier 271 of each TL to be updated and the update timing 272 of that TL.

Here, FIG. 9 is a diagram illustrating an example of hardware included in each information processing device in the certificate verification system 1. Each information processing device includes a processing device 61 (processor) such as a CPU (Central Processing Unit), a DSP (Digital Signal Processor), a GPU (Graphics Processing Unit), an FPGA (Field-Programmable Gate Array), and a ROM (Read Only Memory). ), a main storage device 62 (memory) such as RAM (Random Access Memory), an auxiliary storage device 63 (memory) such as HDD (Hard Disk Drive), SSD (Solid State Drive), and NIC (Network Interface Card),
The communication device 64 includes a wireless communication module, a USB (Universal Serial Interface) module, a serial communication module, or the like. Note that each information processing device may include an input device 65 configured with a mouse, a keyboard, or the like, and an output device 66 configured with a liquid crystal display, an organic EL (Electro-Luminescence) display, or the like.

The functions of each information processing device described above are realized by the processing device 61 reading and executing a program stored in the main storage device 62 or the auxiliary storage device 63. Further, the program can be recorded on a recording medium and distributed, for example. Note that each information processing device may be, in whole or in part, a virtual information processing resource provided using virtualization technology, process space separation technology, etc., such as a virtual server provided by a cloud system. It may be realized using. Furthermore, all or part of the functions provided by each information processing device may be realized by, for example, a service provided by a cloud system via an API (Application Programming Interface) or the like.
Next, the processing performed in the certificate verification system 1 will be explained.

<Processing overview>
FIG. 10 is a diagram illustrating an overview of the processing performed by the certificate verification system 1.
The certificate verification server 50 executes a TL acquisition process s1 that acquires and updates information regarding the TL at the timing indicated by the update setting value information 270. The certificate verification server 50 stores the execution result of the TL acquisition process s1 in the certificate store 100 and the TL management store 200.

The certificate verification server 50 also waits to receive request information (hereinafter referred to as a verification request) including a public key certificate to be verified from the verification requester terminal 10. Upon receiving the verification request, the certificate verification server 50 verifies the public key certificate based on the certificate store 100 and the TL management store 200, and sends the resulting information (hereinafter referred to as verification result) to the verification requester terminal 10. A certificate verification process s3 is executed to reply to the certificate.
Next, details of the TL acquisition process s1 and the certificate verification process s3 will be explained.

<TL acquisition process>
FIG. 11 is a flow diagram illustrating an example of the TL acquisition process s1. The TL acquisition process s1 is repeatedly executed at the timing specified by the update setting value information 270.

The TL store management unit 56 acquires the location information of the TL to be executed (the TL that is the origin; hereinafter referred to as the origin TL) from a database that records information on the country that is the origin of the TL (s101). In this embodiment, it is assumed that the TL store management unit 56 acquires the URL of a TL in a predetermined country.

The TL store management unit 56 acquires the contents of the origin TL based on the location information acquired in s103 (s103). Specifically, the TL store management unit 56 specifies the TL publishing site 30 of the origin TL using the URL acquired in s101, and acquires TL information from the specified TL publishing site 30. In this embodiment, it is assumed that the TL information is acquired as xml (eXtensible Markup Language).

The TL store management unit 56 acquires the TL signature certificate regarding the origin TL acquired in s103 (s105). Specifically, the TL store management unit 56 acquires the data of the TL signature certificate from the TL signature certificate public site 40 associated with the TL acquired in s103.

The TL store management unit 56 verifies the signature of the origin TL acquired in s103, and confirms that the origin TL has not been tampered with (s107). Specifically, the TL store management unit 56 extracts a public key from the TL signature certificate obtained in s105, and uses the extracted public key to decrypt the signature of the origin TL obtained in s103. Check for tampering.

After verifying the signature of the origin TL in s107, the TL store management unit 56 stores information on the origin TL in the TL management store 200 (s109). For example, the TL store management unit 56 stores the URL of the origin TL obtained in s101 and the information on the origin TL obtained in s103 in the TL management table 210.

The TL store management unit 56 executes a TL path construction verification process s111 that constructs a connection relationship (that is, a TL path) between TLs starting from the origin TL and verifies the validity of each TL. Details of the TL path construction verification process s111 will be described later.

The TL store management unit 56 extracts certificate authority information (TSP information) from each TL of the TL path verified in the TL path construction verification process s111, and stores the extracted TSP information in the TSP management table 250. (s113).

The TL store management unit 56 extracts information on the certificate authority (CA certificate) from the TSP information extracted in s113, and stores the extracted CA certificate in the certificate management table 110 (s115). With this, the TL acquisition process s1 ends.
Here, details of the TL path construction verification process s111 will be explained.

<TL path construction verification process>
FIG. 12 is a flow diagram illustrating details of the TL path construction verification process s111.
The TL store management unit 56 attempts to acquire pointers to one or more other TLs (hereinafter referred to as second TLs) indicated by the origin TL acquired in s103 (s201).

The TL store management unit 56 checks whether the pointer was acquired in s201 (s203). If the pointer could be acquired (s203: Yes), the TL store management unit 56 executes the process of s205, and if the pointer could not be acquired (s203: None), the TL path construction verification process s111 ends. .

In s205, the TL store management unit 56 selects one of the second TLs indicated by the pointer obtained in s201, and obtains the URL and public key certificate of the selected second TL.

Then, the TL store management unit 56 obtains the TL information of the selected second TL by accessing the URL (TL public site 30) obtained in s205 (s207).

The TL store management unit 56 verifies the signature of the second TL acquired in s207, and confirms that the selected second TL has not been tampered with (s209). Specifically, the TL store management unit 56 extracts the public key from the public key certificate acquired in s205, and uses the extracted public key to decrypt the signature of the second TL acquired in s207, thereby decrypting the signature of the second TL. Check for tampering.

If the signature of the second TL can be verified in s209, the TL store management unit 56 stores information on the selected second TL in the TL management table 210 (s211). For example, the TL store management unit 56 stores the public key certificate acquired in s205 in the certificate 218 of the TL management table 210.

Subsequently, the TL store management unit 56 attempts to acquire pointer information of one or more other TLs (hereinafter referred to as third TLs) indicated by the second TL acquired in s201 (s213).

The TL store management unit 56 checks whether the pointer was acquired in s213 (s215). If the pointer could be acquired (s215: Yes), the TL store management unit 56 executes the process in s217, and if the pointer could not be acquired (s215: None), the TL store management unit 56 executes the process in s229. Execute processing.

In s229, the TL store management unit 56 attempts to obtain a pointer of another TL that has not been selected so far in the first TL. After that, the processing from s203 onwards is repeated.

On the other hand, in s217, the TL store management unit 56 selects one of the third TLs indicated by the pointer obtained in s213, and obtains the URL and public key certificate of the selected third TL.

Then, the TL store management unit 56 acquires the TL information of the third TL by accessing the URL (TL public site 30) acquired in s217 (s219).

The TL store management unit 56 verifies the signature of the third TL acquired in s219, and confirms that the third TL has not been tampered with (s221). Specifically, the TL store management unit 56 extracts the public key from the public key certificate obtained in s217, and uses the extracted public key to decrypt the signature of the 3rd TL obtained in s219, thereby decrypting the signature of the 3rd TL. Check for tampering.

When the TL store management unit 56 is able to verify the signature of the third TL in s221, it stores information on the selected third TL in the TL management table 210 (s223). For example, the TL store management unit 56 stores the public key certificate acquired in s217 in the certificate 218 of the TL management table 210.

The TL store management unit 56 stores location information of the origin TL, the selected second TL, and the selected third TL in the TL path management table 230. For example, the TL store management unit 56 stores the URL of the origin TL, the URL of the second TL, and the URL of the third TL in the TL path (URL) 234 of the TL path management table 230. Further, the TL store management unit 56 stores the scheme name of the origin TL, the scheme name of the second TL, and the scheme name of the third TL in the TL path (scheme name) 233 of the TL path management table 230.

The TL store management unit 56 attempts to obtain another pointer of the third TL (s227). After that, the process of s215 is performed.

As described above, in the present embodiment, the TL store management unit 56 identifies a TL path consisting of three TLs and creates the TL management table 210 and the TL path management table 230. Similar processing is performed when specifying a TL path.
Next, details of the certificate verification process s3 will be explained.

<Certificate verification process>
FIG. 13 is a flow diagram illustrating an example of the certificate verification process s3. The certificate verification process s3 is performed at a predetermined timing (for example, at a predetermined time, at a predetermined time interval) when a predetermined input is made by the user to the certificate verification server 50, for example, when the certificate verification server 50 is started. executed.

First, the verification request reception unit 51 receives a verification request from the verification requester terminal 10 (s301). The verification request receiving unit 51 then delivers information obtained by removing predetermined header information and the like from the received verification request (hereinafter referred to as an OCSP request) to the certificate verification common processing unit 53 (s303).

(OCSP request)
FIG. 14 is a diagram showing an example of the data format of the OCSP request 700. The OCSP request 700 has each information area: an OCSP basic area 701 where basic information of a verification request is set, and an OCSP extended area 702 where extended information of a verification request is set. In the OCSP basic area 701, basic information contents 703 (for example, information according to the regulations of RFC2560) are set. In the OCSP extension area 702, verification target certificate information 704 (in this embodiment, an X.509 certificate) is set. Further, the OCSP extension area 702 is optionally attached with trust anchor (anchor point) information 705 (in this embodiment, an X.509 certificate) in the bridge model.
Trust anchor information 705 is information added by the person to be verified when the certificate to be verified is used in the bridge model.

Next, as shown in FIG. 13, in s305 to s313, the certificate verification common processing unit 53 executes bridge model verification processing to verify the verification target certificate based on the bridge model.

First, as shown in s305, the certificate verification common processing unit 53 determines whether a bridge model trust anchor is set in the acquired OCSP request 700. Specifically, the certificate verification common processing unit 53 determines whether trust anchor information 705 is set in the OCSP extension area 702 of the OCSP request 700.

If the bridge model trust anchor is set in the OCSP request 700 (s305: Yes), the certificate verification common processing unit 53 executes the process in s307, and the bridge model trust anchor is set in the OCSP request 700. If not (s305: none), the certificate verification common processing unit 53 executes the process of s315.

In s307 and s309, the certificate verification common processing unit 53 searches the certificate store 100 and determines whether the trust anchor information of the verification request is registered. For example, the certificate verification common processing unit 53 refers to each record in the certificate management table 110 and determines whether the trust anchor information 705 included in the verification request is the subject name 113 in the certificate management table 110, the subject key identifier 114 and serial number 115 is found.

If the trust anchor information of the verification request is registered in the certificate store 100 (s309: Yes), the certificate verification common processing unit 53 executes the process of s311, and registers the trust anchor information of the verification request in the certificate store 100. If the information is not registered (s309: none), the certificate verification common processing unit 53 executes the process of s313.

Note that the certificate verification common processing unit 53 executes the process of s313 even when "bridge model" is not specified in the trust model 116 of the record related to the verification target certificate in the certificate management table 110.

In s313, the certificate verification common processing unit 53 sends an OCSP response containing error information indicating that the trust anchor information of the verification request is not registered in the certificate store 100 (the validity of the certification target certificate included in the OCSP request 700). information indicating the result of the gender verification), and then performs the process of s327.

In s311, the certificate verification common processing unit 53 calls the construction and verification process s311 to construct the verifier's (certificate) based on the verifier's trust anchor (hereinafter referred to as bridge model trust anchor) indicated by the OCSP request 700. ) to the person to be verified (certificate of) (certificate path), verify the validity of each certificate in that certification path, and create an OCSP response. . Details of the construction and verification process s311 will be described later. Thereafter, the certificate verification common processing unit 53 performs the process of s327.

In the processes from s315 to s325, the certificate verification common processing unit 53 executes a trust list verification process that verifies the verification target certificate using the trust list.
That is, in s315 and s317, the certificate verification common processing unit 53 refers to the certificate store 100 and checks the certificate of the trust anchor (CA certificate) and the upper certificate authority that has a trust relationship with the certificate authority related to the trust anchor. attempt to obtain CA certificate information. The certificate verification common processing unit 53 checks whether these CA certificates are registered in the trust list and the name of the country (TL management country) in the trust list.

Specifically, the certificate verification common processing unit 53 searches each record of the certificate management table 110 using the issuer of the certificate to be verified as a search key, and obtains the contents of each record found in the search. The certificate verification common processing unit 53 also checks the TL publication presence/absence 117 and country name 118 of the acquired record.

If the CA certificate is registered in the certificate store 100 (s317: Yes), the certificate verification common processing unit 53 executes the process in s319, and the CA certificate is not registered in the certificate store 100. If (s317: none), the certificate verification common processing unit 53 executes the process of s323.

Note that the certificate verification common processing unit 53 executes the process of s323 even when "trusted list" is not specified in the trust model 116 of the record related to the verification target certificate in the certificate management table 110.

In s323, the certificate verification common processing unit 53 creates an OCSP response including error information indicating that the CA certificate is not registered in the certificate store 100, and then performs the process in s327.

In s319, the certificate verification common processing unit 53 calls the construction and verification process s311, and performs verification from the server setting trust anchor based on the CA certificate (hereinafter referred to as server setting trust anchor) obtained in s315 (search hit). Constructs a linkage (certification path) of each certificate (certificate authority) up to the target certificate and verifies the validity of each certificate in that certification path.

Subsequently, the certificate verification common processing unit 53 determines whether the certificate included in the OCSP request 700 is registered in the trust list (s321).

If the certificate indicated by the OCSP request 700 is registered in the trust list (s321: Yes), the certificate verification common processing unit 53 executes additional processing s325, which will be described later, and the certificate indicated by the OCSP request 700 is registered in the trust list. If the certificate is not registered in s321 (s321: none), the certificate verification common processing unit 53 executes the process of s327.

In s327, the certificate verification common processing unit 53 delivers the created OCSP response to the verification result response unit 52. The verification result response unit 52 creates a verification response, which is data corresponding to the verification request, by adding predetermined header information, etc. to the received OCSP response, and delivers the created verification response to the verification request reception unit 51. . The verification request reception unit 51 transmits the received verification response to the verification requester terminal 10 (s329).

(OCSP response)
FIG. 15 is a diagram showing an example of the data format of the OCSP response 800. The OCSP response 800 has each information area: an OCSP basic area 801 where basic information of the verification response is set, and an OCSP extended area 802 where extended information of the verification response is set. In the OCSP basic area 801, basic information contents 803 (for example, information according to the regulations of RFC2560) are set. Information regarding the verification result of the target certificate (result code 804) is set in the OCSP extension area 802. Further, in the OCSP extension area 802, when trust anchor information is not set in the verification request and a trust anchor is set on the server side (server setting transanchor), the certificate 805 of the trust anchor is set. . Furthermore, verification information 806 that is created when additional processing s325 is executed is set in the OCSP extension area 802.
Here, details of the additional process s325 will be explained.

<Additional processing>
FIG. 16 is a diagram illustrating details of the additional process s325.

The TL method verification addition processing unit 54 verifies the TL path in the trust list by referring to the TL management store 200 (s401). Specifically, the TL method verification addition processing unit 54:
Referring to the TL path management table 230, there is a record of a TL path in which the already set (s101) origin TL is the starting point of the TL path and the issuer of the verification target certificate in the verification request is the end point of the TL path. Check whether or not.

Further, the TL method verification addition processing unit 54 verifies the validity of each trust list in the TL path acquired in s401 by referring to the TL management store 200 (s403). Specifically, the TL method verification addition processing unit 54 refers to the TL management table 210 and selects the issue date and time 213 and the record in which the scheme name of each TL of the TL path specified in s401 is set in the TL scheme name 212. The validity of each trust list is verified by referring to the next update date and time 214.

Further, the TL method verification addition processing unit 54 verifies the quality of each trust list in the TL path specified in s401 by referring to the TL management store 200 (s405). Specifically, the TL method verification addition processing unit 54 refers to the TSP management table 250 and selects the service of the record in which the service name of the certification authority is set as the service name 253 in each trust list of the TL path specified in s401. Obtain information extension 255.

Then, the TL method verification addition processing unit 54 creates verification data (verification report) that integrates the verification contents in s401 to s405 (s407). The TL method verification addition processing unit 54 adds the created verification data to the OCSP response 800 as part of the OCSP response (s409). Note that, if the verification fails in any of steps s401 to s405, the TL method verification addition processing unit 54 adds error information indicating this to the OCSP response 800 as part of the OCSP response 800.
Next, details of the construction and verification process s111 will be explained.

<Construction and verification process>
FIG. 17 is a flow diagram illustrating the process related to the construction of a certification path in the construction and verification process s111.

The certificate verification common processing unit 53 acquires the CA certificate of the certification authority that issued the verification target certificate from the certification authority server 20 (s501).

The certificate verification common processing unit 53 checks whether the acquired CA certificate is a self-signed certificate (signer's trust anchor) (s503). If the acquired CA certificate is a self-signed certificate (s503: yes), the certificate verification common processing unit 53 executes the process of s507, and if the acquired CA certificate is not a self-signed certificate (s503: : No), the certificate verification common processing unit 53 executes the process of s505.

In s505, the certificate verification common processing unit 53 refers to the CA certificate currently being acquired, and acquires the CA certificate of the higher-ranking certificate authority of the CA certificate. After that, the process of s503 is repeated.

In s507, the certificate verification common processing unit 53 determines whether the self-signed certificate (trans anchor of the signer) specified in s503 matches the trust anchor (bridge model trust anchor or server setting trust anchor). do.

If the self-signed certificate specified in s503 and the trust anchor match (s507: yes), the certificate verification common processing unit 53 executes the process in s513, and compares the self-signed certificate specified in s503 with the trust anchor. If they do not match (s507: No), the certificate verification common processing unit 53 executes the process of s509. Note that when performing verification processing without including a self-signed certificate in the certification path, the certificate verification common processing unit 53 performs the processing in S503 and S505 up to the highest intermediate CA certificate, and then performs the processing in S507. Perform subsequent processing.

In s509, the certificate verification common processing unit 53 sends the mutual authentication certificate issued by the verifier's transanchor (certificate authority) indicated by the OCSP request 700 to another certificate authority that has performed mutual authentication to the TL public site 30, etc. Get it from the repository.

Furthermore, the certificate verification common processing unit 53 obtains, from the repository of the certificate authority, a mutual authentication certificate issued by the other certificate authority to the signer's transanchor, which is another certificate authority that has performed mutual authentication. (s511).

The certificate verification common processing unit 53 stores each certificate from the verifier's trust anchor (certificate authority) to the verification target certificate specified in s509 and s511 as a certification path (s513).

Although a case has been described here in which a certification path is constructed by three mutually authenticated certification authorities, the same process is performed when a certification path is constructed by four or more certification authorities.

FIG. 18 is a flowchart illustrating processing related to certification path verification (certificate validity verification) in the construction and verification processing s111. This process is performed following the process up to s513 described above.

The certificate verification common processing unit 53 sets the certificate of the verifier's transanchor (certification authority) that is the starting point as "certificate 1" for each certificate x of the certification path constructed in the processing up to s513, and A certain verification target certificate is certificate n (n: number of all certificates), and the authentication target for "certificate x" (x: 1 to n) is the issuer name of the certificate for "certificate x+1". Each "certificate x" is arranged as follows (s601).

The certificate verification common processing unit 53 confirms that the verification time (for example, the current time) is the expiration date of the "certificate x" for each "certificate x" sorted in s601. Note that when the certificate verification common processing unit 53 detects a certificate whose verification time is not the expiration date, the certificate verification common processing unit 53 may generate error information and use it as the OCSP response 800.

The certificate verification common processing unit 53 sets the "certificate x" to be processed as "certificate 2" (s605).

The certificate verification common processing unit 53 confirms that the "certificate x" to be processed is signed with the private key corresponding to the public key of "certificate x-1" (s607). Note that if "certificate x" is not signed with the private key corresponding to the public key of "certificate You can also use it as

The certificate verification common processing unit 53 sets the "certificate x" to be processed as the next certificate ("certificate x+1") (s609). Then, the certificate verification common processing unit 53 determines whether the "certificate x" to be processed is "certificate n" (s611).

If the "certificate x" to be processed is "certificate n" (s611: yes), the certificate verification common processing unit 53 executes the process in s613, and the "certificate x" to be processed is "certificate n" (s611: yes). If the certificate is not "certificate n" (s611: yes), the certificate verification common processing unit 53 repeats the processing from s607 onward.

In s613, the certificate verification common processing unit 53 confirms that each "certificate x" has not been revoked. For example, the certificate verification common processing unit 53 obtains revocation information from each certificate authority server 20, and confirms that each "certificate x" has not been revoked based on the obtained revocation information. Note that the certificate verification common processing unit 53 may generate error information as the OCSP response 800 if there is an expired certificate.

Note that the certificate verification common processing unit 53 refers to the extended area of each "certificate x" and executes processing according to the information (KeyUsage, predetermined policy) set in the extended area (s615). This process may be omitted in some cases. This completes the process related to the construction of the authentication path.

As described above, the certificate verification server 50 of the present embodiment uses information about the connection relationship between the trust lists and the validity of each trust list (TL management table 210 and TL path management table 230), and information on certificate authorities registered in the trust list whose connection relationships and validity have been confirmed (TSP management table 250 and certificate management table 110), respectively. When a verification request is received from the verification requester terminal 10, the connection relationship between the certification authority of the verification target certificate and the trust anchor is determined based on the certificate information (trust anchor) of the certification authority specified from each database. A verification response that verifies the validity of each certificate authority's certificate is transmitted to the verification requester terminal 10.

In this way, the certificate verification server 50 of this embodiment stores, as a trust anchor, the certificate of the TL for which the construction of a plurality of TL paths and the verification of each certificate of the TL path (signature verification) have been successful. The certificate to be verified can be verified using a truss anchor. That is, according to the certificate verification server 50 of this embodiment, even if a plurality of trust lists exist, a certificate can be verified based on a highly reliable trust anchor.

Further, the certificate verification server 50 of this embodiment executes the trust list verification process when the verification request does not have a trust anchor attached, and when the verification request has a trust anchor attached, Based on the verification target certificate and its trust anchor, a certification path is constructed and verified, and verification is performed using the bridge model.

As a result, even if the verification target certificate does not support the TL but only supports the bridge model, it is possible to perform verification using the bridge model based on the trust anchor attached to the verification request. That is, the certificate verification server 50 can automatically determine the verification method to be used for verifying the certificate.

Further, the certificate verification server 50 of this embodiment repeatedly executes the trust list acquisition process at a timing preset in the update setting value information 270.

In this way, by importing TL information at any time, it is possible to reduce the processing load of constructing and verifying a TL path and improve the accuracy of certificate verification.

Further, the certificate verification server 50 of this embodiment stores certificates of certificate authorities registered in the trust list whose linkage and validity have been confirmed in the certificate management table 110, and includes a trust anchor in the verification request. If it is not attached, a trust list verification process is executed based on the certificate information (trust anchor) of the certificate authority registered in the certificate management table 110.

In this way, by verifying a certificate using a trust list using the certificate management table 110 in which only trust lists whose connection relationships and validity have been confirmed are registered, highly reliable verification can be performed. can.

Further, the certificate verification server 50 of this embodiment receives input from the user of the verification method supported by the certificate to be verified (trust model 116 of the certificate management table 110), and receives a verification request. In this case, the trust list verification process is executed only when the trust model 116 specifies a certificate verification method using a trust list.

Thereby, the certificate can be verified in accordance with the verification method supported by the certificate to be verified.

Furthermore, when executing the trust list verification process, the certificate verification server 50 of this embodiment creates a verification report of the trust list in which the TL path has been constructed and verified, and sends the verification response including the verification report to the verification report. It is transmitted to the client terminal 10.

Thereby, the reliability of the trust list can be increased by providing the verification requester terminal 10 with information on the quality of the certificate in the trust list, such as QC/QSCD determination.

The present invention is not limited to the embodiments described above, and can be implemented using arbitrary components without departing from the spirit thereof. The embodiments and modifications described above are merely examples, and the present invention is not limited to these contents as long as the characteristics of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments considered within the technical spirit of the present invention are also included within the scope of the present invention.

For example, some of the functions included in each device of this embodiment may be provided in another device, or functions provided in another device may be provided in the same device.

Further, the configuration of the program described in this embodiment is an example, and for example, a part of the program may be incorporated into another program, or a plurality of programs may be configured as one program.

1 Certificate verification system 10 Verification requester terminal 50 Certificate verification server

Claims (14)

comprising a processor and a memory, the processor comprising:
Based on the information on the plurality of trust lists received from the first information processing device, information on the connection relationship between the plurality of trust lists and the validity of the plurality of trust lists, and the connection relationship and validity are confirmed. a store management process of executing a trust list acquisition process of acquiring information of each certificate authority registered in the trust list and storing it in the memory;
When a verification request including a certificate to be verified is received from a second information processing device, the certificate to be verified indicates based on the information of the certificate of the certification authority identified from the information stored in the memory. a certificate verification common process that executes a trust list verification process that verifies the connection relationship between the certification authority and the identified certification authority and the validity of the certificate of each certification authority;
A certificate verification device that performs a verification result response process of transmitting the verified result to the second information processing device. In the certificate verification common process, the processor:
It is determined whether the received verification request is accompanied by a trust anchor, which is a certificate trusted by the verifier, and if the trust anchor is not attached to the verification request, the trust list verification is performed. execute the process,
If the trust anchor is attached to the verification request, based on the verification target certificate and the trust anchor, the certificate authority specified by the verification target certificate and the certificate authority indicated by the trust anchor are determined. executing a bridge model verification process for verifying the connection relationship between the certificate authorities and the validity of the certificate of each of the certificate authorities, and transmitting the verification results to the second information processing device;
The certificate verification device according to claim 1. The processor includes:
The certificate verification device according to claim 1, wherein in the store management process, the trust list acquisition process is repeatedly executed at a preset timing. The processor includes:
In the store management process, storing in the memory a certificate of a certification authority registered in the trust list whose connection relationship and validity have been confirmed;
In the certificate verification common processing, if a trust anchor is not attached to the received verification request, the certificate authority registered in the trust list stored in the memory and whose linkage relationship and validity have been confirmed. executing the trust list verification process based on the information of the certificate;
The certificate verification device according to claim 2. further comprising an input device;
The processor includes:
receiving from a user an input of a verification method supported by the certificate to be verified, using the input device;
In the certificate verification common processing, when the verification request is received, it is determined whether the certificate verification method using the trust list is specified as the input verification method, and the input verification method is Executing the trust list verification process only when a certificate verification method using the trust list is specified in
The certificate verification device according to claim 1. The processor includes:
Executing a TL method verification additional process that creates information indicating the quality of the trust list related to the certificate authority that verified the connection relationship and the validity when executing the trust list verification process, based on the information stored in the memory. death,
In the verification result response process, transmitting the verified result including the created information to the second information processing device;
The certificate verification device according to claim 1. In an information processing device including a processor and a memory, the processor
Based on the information on the plurality of trust lists received from another first information processing device, information on the connection relationships among the plurality of trust lists and the validity of the plurality of trust lists; a store management process of executing a trust list acquisition process of acquiring information of each of the certificate authorities registered in the confirmed trust list and storing it in the memory;
When a verification request including a certificate to be verified is received from another second information processing device, the certificate to be verified is determined based on the information on the certificate of the certification authority identified from the information stored in the memory. a certificate verification common process that executes a trust list verification process that verifies the connection relationship between the certificate authority indicated by and the identified certificate authority, and the validity of the certificate of each of the certificate authorities;
and transmitting the verified result to the second information processing device. The processor,
In the certificate verification common process, it is determined whether the received verification request is attached with a trust anchor, which is a certificate trusted by the verifier, and the verification request is not attached with the trust anchor. If so, execute the trust list verification process,
If the trust anchor is attached to the verification request, based on the verification target certificate and the trust anchor, the certificate authority specified by the verification target certificate and the certificate authority indicated by the trust anchor are determined. executing a bridge model verification process for verifying the connection relationship between the certificate authorities and the validity of the certificate of each of the certificate authorities, and transmitting the verification results to the information processing device;
The certificate verification method according to claim 7. The processor,
8. The certificate verification method according to claim 7, wherein in the store management process, the trust list acquisition process is repeatedly executed at a preset timing. The processor,
In the store management process, storing in the memory a certificate of a certification authority registered in the trust list whose connection relationship and validity have been confirmed;
In the certificate verification common processing, if a trust anchor is not attached to the received verification request, the certificate authority registered in the trust list stored in the memory and whose linkage relationship and validity have been confirmed. executing the trust list verification process based on the information of the certificate;
The certificate verification method according to claim 8. The information processing device further includes an input device,
The processor,
receiving from a user an input of a verification method supported by the certificate to be verified, using the input device;
In the certificate verification common processing, when the verification request is received, it is determined whether the certificate verification method using the trust list is specified as the input verification method, and the input verification method is Executing the trust list verification process only when a certificate verification method using the trust list is specified in
The certificate verification method according to claim 7. The processor,
When executing the trust list verification process, TL method verification additional processing is performed to create information indicating the quality of the trust list related to the connection relationship and the certificate authority that verified the validity based on the information stored in the memory. execute,
In the verification result response process, transmitting the verified result including the created information to the second information processing device;
The certificate verification method according to claim 7. The processor of an information processing device including a processor and a memory,
Based on the information on the plurality of trust lists received from another first information processing device, information on the connection relationships among the plurality of trust lists and the validity of the plurality of trust lists; a store management process of executing a trust list acquisition process of acquiring information of each of the certificate authorities registered in the confirmed trust list and storing it in the memory;
When a verification request including a certificate to be verified is received from another second information processing device, the certificate to be verified is determined based on the information on the certificate of the certification authority identified from the information stored in the memory. a certificate verification common process that executes a trust list verification process that verifies the connection relationship between the certificate authority indicated by and the identified certificate authority, and the validity of the certificate of each of the certificate authorities;
and a verification result response process of transmitting the verified result to the other second information processing device. a first information processing device that transmits information on a plurality of trust lists;
a second information processing device that transmits a verification request including a certificate to be verified;
comprising a processor and a memory, the processor comprising:
Based on the information on the plurality of trust lists received from the first information processing device, information on the connection relationship between the plurality of trust lists and the validity of the plurality of trust lists, and the connection relationship and validity are confirmed. a store management process of executing a trust list acquisition process of acquiring and storing information of each certificate authority registered in the trust list in the memory;
When a verification request including a certificate to be verified is received from the second information processing device, the certificate to be verified is verified based on the information of the certificate of the certification authority identified from the information stored in the memory. a certificate verification common process that executes a trust list verification process that verifies the connection relationship between the indicated certificate authority and the specified certificate authority, and the validity of the certificate of each of the certificate authorities;
and a certificate verification device that performs a verification result response process of transmitting the verified result to the second information processing device.

Images