Certificate verification device, certificate verification method, program, and certificate verification system

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

[Technical Field]

[0001] The present invention relates to a certificate validation device, a certificate validation method, a program, and a certificate validation system. [Background technology]

[0002] Digital certificates are now widely used for electronic contracts, such as electronic applications. Accordingly, there are now many certification authorities that manage digital certificates. Therefore, models for mutual authentication between multiple certification authorities have been proposed. Typical methods for mutual authentication between certification authorities include the bridge model and trusted lists.

[0003] Compared to cross-certification based on the bridge model, cross-certification based on trust lists has the advantage of requiring less processing load to establish certification relationships between certification authorities and verify each certificate (building and verifying certification paths). On the other hand, cross-certification based on trust lists requires processing specific to trust lists, such as building and verifying relationships between trust lists. Furthermore, with trust lists, management of trust anchors, which are the starting points for trust in certificates (certification authorities), can be more complicated than with the bridge model. In particular, when trust lists are used across multiple countries or regions, the management and processing load is expected to increase.

[0004] In this regard, Non-Patent Documents 1 and 2 disclose a method for mutually authenticating certificates among EU member states in a model using a trust list (TL model).

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

[0006] [Patent Document 1] Japanese Patent Application Laid-Open No. 2006-148454 [Patent Document 2] Japanese Patent Publication No. 2020-010396 [Non-patent literature]

[0007] [Non-Patent Document 1] "ETSI TS 119 172-4 V1.1.1", [online], [Retrieved February 25, 2022], Internet,<URL:https: / / standards.globalspec.com / std / 14387063 / ts-119-172-4> [Non-patent document 2] "ETSI TS 119 615 V1.1.1", [online], [Retrieved February 25, 2022], Internet, <URL:https: / / www.etsi.org / deliver / etsi_ts / 119600_119699 / 119615 / 01.01.01_60 / ts_119615v010101p.pdf> Summary of the Invention [Problem to be solved by the invention]

[0008] However, Non-Patent Documents 1 and 2 do not take into consideration the case where trust lists are shared with regions other than EU member states.

[0009] Furthermore, Patent Document 1 consolidates and manages certificates, but is unable to verify the trust relationships between them. Patent Document 2 discloses a method of issuing certificates that describe multiple cryptographic algorithms and signature values, and verifying the signature using an algorithm that the verifier can support, but because the verification method cannot be embedded in the certificate description, it cannot be applied to determining the certificate method. Furthermore, when the bridge model and trust lists coexist in the market, certificate verifiers cannot determine whether the certificate should be verified using the bridge model or the trust list simply by referring to the certificate to be verified.

[0010] The present invention has been made in light of this current situation, and its purpose is to provide a certificate validation device, a certificate validation method, a program, and a certificate validation system that are capable of verifying certificates based on a highly reliable trust anchor even when multiple trust lists exist. [Means for solving the problem]

[0011] One aspect of the present invention for solving the above problem is a certificate verification device that includes a processor and a memory, and that executes a store management process in which the processor executes a trust list acquisition process to acquire, based on information about a plurality of trust lists received from a first information processing device, information about the connection relationships between the plurality of trust lists and the validity of the plurality of trust lists, and information about certification authorities registered in the trust lists whose connection relationships and validity have been confirmed, and store these in the memory; a certificate verification common process in which, when a verification request including a certificate to be verified is received from a second information processing device, the processor executes a trust list verification process to verify, based on information about the certificate of the certification authority identified from the information stored in the memory, 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 of the certification authorities; and a verification result response process to send the verification results to the second information processing device. [Effects of the Invention]

[0012] According to the present invention, even when multiple trust lists exist, certificate verification can be performed based on a highly reliable trust anchor. Configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a diagram illustrating an example of the configuration of a certificate validation system according to an embodiment of the present invention. [Figure 2] 2 is a diagram illustrating an example of the configuration of a bridge model and a TL model in the certificate validation system of the present embodiment. FIG. [Figure 3] FIG. 10 is a diagram illustrating an example of the data structure of a TL. [Figure 4] FIG. 10 is a diagram illustrating an example of a TL management table. [Figure 5] FIG. 10 is a diagram illustrating an example of a TL path management table. [Figure 6] FIG. 10 is a diagram illustrating an example of a TSP management table. [Figure 7]FIG. 10 illustrates an example of a certificate management table. [Figure 8] FIG. 10 is a diagram illustrating an example of updated setting value information. [Figure 9] FIG. 2 is a diagram illustrating an example of hardware included in each information processing device in the certificate validation system. [Figure 10] FIG. 1 is a diagram illustrating an overview of processing performed in a certificate validation system. [Figure 11] FIG. 10 is a flow diagram illustrating an example of a TL acquisition process. [Figure 12] FIG. 10 is a flowchart illustrating details of a TL path construction verification process. [Figure 13] FIG. 10 is a flow diagram illustrating an example of a certificate verification process. [Figure 14] FIG. 10 is a diagram illustrating an example of a data format of an OCSP request. [Figure 15] FIG. 10 is a diagram illustrating an example of a data format of an OCSP response. [Figure 16] FIG. 10 is a diagram illustrating details of the addition process. [Figure 17] FIG. 10 is a flowchart illustrating a process related to the construction of a certification path, among the construction and verification processes. [Figure 18] FIG. 10 is a flow diagram illustrating the process of verifying a certification path (verifying the validity of a certificate) in the construction and verification process. DETAILED DESCRIPTION OF THE INVENTION

[0014] 1 is a diagram showing an example of the configuration of a certificate validation system 1 according to this embodiment. The certificate validation system 1 includes a plurality of validation requester terminals 10 (10a,...,10n) (second information processing devices) used by users who send and receive data such as electronic documents to which digital certificates issued by a certification authority (hereinafter simply referred to as certificates) are attached, one or more certification authority servers 20 (30a,...,30n) managed by the certification authorities that issue the certificates, and a plurality of TL publication sites that publish information on trusted lists (TLs; hereinafter referred to as TLs), which are data that manages a list of certification authorities that have built mutual trust relationships and mutually authenticated each other. The system is composed of information processing devices 30 (30a,...,30n) (first information processing device), multiple TL signature certificate disclosure sites 40 (40a,...,40n) that disclose public key certificates for verifying TLs, and a certificate validation server 50 (certificate validation device) described later.

[0015] The validation requester terminal 10, the certification authority server 20, the TL disclosure site 30, the TL signature certificate disclosure site 40, and the certificate validation server 50 are connected to each other via wired or wireless communication such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line. Communication is possible via network 5.

[0016] In the Certificate Validation System 1, the reliability of each certification authority (the interconnected relationships between certification authorities and the validity of each certification authority's certificate) is ensured by the TL, which is a list of certification authorities trusted by administrators in each country or region, and the bridge model, which is a network of mutually recognized certificates exchanged between two certification authorities.

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

[0018] First, in bridge model 500, mutual authentication is performed between certification authority CA1 and certification authority BCA, between certification authority BCA and certification authority CA2, and between certification authority CA2 and certification authority CA3 by exchanging mutual authentication certificates 501. A mutual authentication certificate issued by the other certification authority to one's own certification authority and a mutual authentication certificate issued by one's own certification authority to the other certification authority are stored as a pair and are called a mutual authentication certificate pair. Mutual authentication certificate pairs are made public on a directory server. Certification authority CA3 directly manages its subordinate certification authorities CA3a and CA3b. Each certification authority (including subordinate certification authorities) issues an EE certificate 503 (EE: End Entity) to the user (EE).

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

[0020] (TL) 3 is a diagram showing an example of an extracted portion of the data configuration of a TL. Each TL 300 includes a pointer 301 to another TL and a signature 304. The pointer 301 has one or more combinations of a public key certificate 302 for verifying its own TL or another TL that has a trust relationship with its own TL, and the location 303 of the other TL (in this embodiment, a URL).

[0021] In the example shown in the figure, the originating "TL C1" identifies "TL A1" by location 303, and verifies the signature 304 of "TL A1" by the public key extracted from the public key certificate 302 of "TL C1" related to "TL A1". "TL A1" identifies "TL C1", "TL C2", and "TL C3", and verifies the signatures 304 of "TL C1", "TL C2", and "TL C3" using the public keys extracted from the public key certificates for "TL A1" regarding "TL C1", "TL C2", and "TL C3".

[0022] Next, as shown in FIG. 1, the certificate validation server 50 includes functional units (programs) including a validation request receiving unit 51, a validation result response unit 52, a certificate validation common processing unit 53, a TL method validation additional processing unit 54, and a store management unit 57.

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

[0024] The verification result response unit 52 transmits a verification response, which is response data to the verification requester terminal 10, to the verification requester terminal 10.

[0025] Based on the information of the multiple trust lists received from the TL disclosure site 30, the store management unit 57 obtains information on the connection relationships between the multiple trust lists and the validity of the multiple trust lists (construction of TL paths and their verification), as well as information on the certificates of the certification authorities registered in the trust lists whose connection relationships and validity have been confirmed, and stores these in the TL management store 200 and the certificate store 100.

[0026] The store management unit 57 includes a certificate store management unit 55 and a TL store management unit 56. The certificate store management unit 55 analyzes certificates from certification authorities and performs processes related to certificate-related information management. The TL store management unit 56 performs processes related to the validity of trust lists and connectivity (such as TL signature verification and path construction between TLs).

[0027] When the certificate validation common processing unit 53 receives a validation request including the certificate to be validated from the validation requester terminal 10, it executes a trust list validation process to validate the connection between the certification authority indicated by the certificate to be validated and the above-mentioned identified certification authority, and the validity of the certificate of each certification authority, based on the information of the certificate of the certification authority identified from the TL management store 200 and the certificate store 100 stored in the store management unit 57.

[0028] In this embodiment, if the validation request does not include a bridge model trust anchor, the certificate validation common processing unit 53 executes the trust list validation process based on the information of the certification authority certificate registered in the certificate store 100 (the trans-anchor uniquely set by the certificate validation server 50).

[0029] The TL method verification additional processing unit 54 creates, based on the TL management store 200, 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.

[0030] The certificate validation server 50 also stores the following databases: a certificate store 100, a TL management store 200, and updated setting value information 270.

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

[0032] (TL management table) 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.

[0033] The TL management table 210 has the following data items: country name 211, which sets the name of the country or region that manages the TL (hereinafter referred to as the TL management country); TL scheme name 212, which sets the name of the scheme of the TL; issue date and time 213, which sets the issue date and time of the TL; next update date and time 214, which sets the next update date and time of the TL; distribution point 215, which sets the distribution point of the TL; and pointer 216, which sets a list of information for each of the other TLs pointed to by the TL.

[0034] The pointer 216 has sub-items of a TL location 217 in which location information (in this embodiment, a URL) of each TL is set, and a certificate 218 in which information indicating the public key certificate of each TL is set. In this embodiment, the public key certificate is assumed to be an X.509 certificate, but the format is not particularly limited.

[0035] (TL path management table) 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) that are configured from a plurality of TLs.

[0036] The TL path management table 230 has the following data items: start point 231, where the start point of the TL path is set; end point 232, where the end point of the TL path is set; TL path (scheme name) 233, where information specifying the TL path by the scheme name is set; and TL path (URL) 234, where information specifying the TL path by location information (URL in this embodiment) is set.

[0037] (TSP management table) 6 is a diagram showing an example of the TSP management table 250. The TSP management table 250 is a database that stores information (hereinafter referred to as TSP information) about businesses (certification authorities in this embodiment) registered in the TL.

[0038] The TSP management table 250 includes a country name 251 in which the TL management country of the TL in which the certification authority is registered is set, a service type identifier 252 in which the identifier of the service provided by the certification authority is set, a service name 253 in which the name of the service of the certification authority is set, a status 254 in which information indicating whether the public key certificate of the certification authority is valid or not is set, and information on the quality of the certification authority certificate (hereinafter also referred to as a CA certificate, CA: Certificate Authority) (for example, The data items are a service information extension 255 in which a Qualified Certificate (QC) and a Qualified Signature Create Device (QSCD) are set, and a certificate 256 in which information specifying the public key certificate of the certification authority is set. The service information extension 255 sets information such as the level of quality of the certification, whether it is used for signing or other purposes, and whether the private key is managed by hardware.

[0039] The certificate store 100 stores a certificate management table 110 . (Certificate Management Table) 7 is a diagram showing an example of a certificate management table 110. The certificate management table 110 is a database that manages detailed information about public key certificates. The certificate management table 110 has the following data items: issuer name 111, in which information about the issuer of the public key certificate (such as a country name or organization name) is set; issuer key identifier 112, in which information about the public key issued by the issuer is set; subject name 113, in which information about the subject certified by the certificate (such as a country name or organization name) is set; subject key identifier 114, in which information about the public key of the subject certified is set; serial number 115, in which the serial number of the certificate is set; trust model 116, in which information indicating the certificate verification method (model type) supported by the public key certificate is set; TL listing status 117, in which a flag indicating whether the public key certificate is registered in the TL is set; and country name 118, in which the country managing the TL is set if the public key certificate is registered in the TL.

[0040] In this embodiment, the bridge model, the TL model, or both of these models is set as the trust model 116. The trust model 116 is set in advance by the user (for example, the certificate validation server 50 displays an input screen and accepts input from the user).

[0041] (Update setting information) 8 is a diagram showing an example of the update setting value information 270. The update setting value information 270 is information that presets the timing at which the certificate validation server 50 acquires and updates information related to the TL.

[0042] The update setting value information 270 is information that includes an identifier 271 of each TL to be updated and the timing 272 of updating the TL.

[0043] 9 is a diagram illustrating an example of hardware included in each information processing device in the certificate validation 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), or an FPGA (Field-Programmable Gate Array), a main storage device 62 (memory) such as a ROM (Read Only Memory) or a RAM (Random Access Memory), an auxiliary storage device 63 (memory) such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive), a NIC (Network Interface Card), and a communication device 64 configured with a wireless communication module, a USB (Universal Serial Interface) module, a serial communication module, etc. Each information processing device may also include an input device 65 configured with a mouse, a keyboard, etc., and an output device 66 configured with a liquid crystal display, an organic EL (Electro-Luminescence) display, etc.

[0044] 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. The program can also be recorded on a recording medium and distributed, for example. Note that all or part of each information processing device may be realized using virtual information processing resources provided using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. Also, all or part of the functions provided by each information processing device may be realized by a service provided by the cloud system via an API (Application Programming Interface), for example. Next, the processing performed by the certificate validation system 1 will be described.

[0045] <Overview of the Process> FIG. 10 is a diagram for explaining the overview of the process performed in the certificate verification system 1. The certificate verification server 50 executes a TL acquisition process s1 for acquiring and updating 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.

[0046] Also, the certificate verification server 50 waits for receiving request information (hereinafter referred to as a verification request) including a public key certificate to be verified from the verifier terminal 10. When the certificate verification server 50 receives the verification request, it executes a certificate verification process s3 for verifying the public key certificate based on the certificate store 100 and the TL management store 200, and returns the result information (hereinafter referred to as a verification result) to the verifier terminal 10. Next, details of the TL acquisition process s1 and the certificate verification process s3 will be described.

[0047] <TL Acquisition Process> FIG. 11 is a flowchart for explaining 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.

[0048] The TL store management unit 56 acquires the location information of the TL to be executed (the starting TL. Hereinafter referred to as the starting TL) from a database or the like in which information on the country that is the starting point of the TL is recorded (s101). In the present embodiment, the TL store management unit 56 acquires the URL of the TL of a predetermined country.

[0049] The TL store management unit 56 acquires the content of the starting TL based on the location information acquired in s103 (s103). Specifically, the TL store management unit 56 identifies the TL public site 30 of the starting TL using the URL acquired in s101, and acquires the information of the TL from the identified TL public site 30. In the present embodiment, the information of the TL is acquired as xml (eXtensible Markup Language).

[0050] The TL store management unit 56 acquires the TL signing certificate for the origin TL acquired in s103 (s105). Specifically, the TL store management unit 56 acquires the data of the TL signing certificate from the TL signing certificate publication site 40 associated with the TL acquired in s103.

[0051] 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 the public key from the TL signature certificate acquired in s105, and decrypts the signature of the origin TL acquired in s103 with the extracted public key, thereby confirming whether the origin TL has been tampered with.

[0052] After verifying the signature of the origin TL in s107, the TL store management unit 56 stores information about 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 about the origin TL obtained in s103 in the TL management table 210.

[0053] The TL store management unit 56 executes a TL path construction verification process s111 for constructing a connection relationship (i.e., a TL path) between TLs starting from the source TL and verifying the validity of each TL. The TL path construction verification process s111 will be described in detail later.

[0054] The TL store management unit 56 extracts the certificate authority information (TSP information) from each TL for 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).

[0055] The TL store management unit 56 extracts information about the certificate authority's certificate (CA certificate) from the TSP information extracted in s113, and stores the extracted CA certificate in the certificate management table 110 (s115). This completes the TL acquisition process s1. Here, the TL path construction verification process s111 will be described in detail.

[0056] <TL Path Construction Verification Process> FIG. 12 is a flowchart for explaining the details of the TL path construction verification process s111. The TL store management unit 56 attempts to obtain pointers to one or more other TLs (hereinafter referred to as second TLs) indicated by the starting TL obtained in s103 (s201).

[0057] The TL store management unit 56 checks whether it has obtained a pointer in s201 (s203). If a pointer has been obtained (s203: yes), the TL store management unit 56 executes the process of s205. If a pointer has not been obtained (s203: no), the TL path construction verification process s111 ends.

[0058] 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.

[0059] Then, the TL store management unit 56 accesses the URL (TL public site 30) obtained in s205 to obtain the TL information of the selected second TL (s207).

[0060] The TL store management unit 56 verifies the signature of the second TL obtained in s207, and checks 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 obtained in s205, and decrypts the signature of the second TL obtained in s207 with the extracted public key to check for tampering of the second TL.

[0061] If the TL store management unit 56 can verify the signature of the second TL in s209, it stores the information of the selected second TL in the TL management table 210 (s211). For example, the TL store management unit 56 stores the public key certificate obtained in s205 in the certificate 218 of the TL management table 210.

[0062] Next, 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).

[0063] The TL store management unit 56 checks whether or not the pointer was acquired in s213 (s215). If the pointer was acquired (s215: Yes), the TL store management unit 56 executes the process of s217, and if the pointer was not acquired (s215: No), the TL store management unit 56 executes the process of s229.

[0064] In s229, the TL store management unit 56 attempts to acquire a pointer to another TL that has not been selected in the first TL. After that, the processing from s203 onwards is repeated.

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

[0066] Then, the TL store management unit 56 accesses the URL (TL disclosure site 30) acquired in s217 to acquire the TL information of the third TL (s219).

[0067] 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 acquired in s217 and decrypts the signature of the third TL acquired in s219 with the extracted public key, thereby confirming whether the third TL has been tampered with.

[0068] If the TL store management unit 56 can verify the signature of the third TL in s221, it stores information about 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.

[0069] 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. In addition, 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.

[0070] The TL store management unit 56 attempts to obtain another pointer of the third TL (s227), after which the process of s215 is carried out.

[0071] In this way, in this 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, but the same processing is also performed when identifying a TL path consisting of four or more TLs. Next, the certificate verification process s3 will be described in detail.

[0072] <Certificate verification process> 13 is a flow diagram illustrating an example of the certificate validation process s3. The certificate validation process s3 is executed at a predetermined timing (for example, at a predetermined time or at predetermined time intervals) when the certificate validation server 50 is started up or when a predetermined input is made to the certificate validation server 50 by the user.

[0073] First, the validation request receiving unit 51 receives a validation request from the validation requester terminal 10 (s301). Then, the validation request receiving unit 51 removes predetermined header information and the like from the received validation request (hereinafter referred to as an OCSP request) and delivers the resulting information to the certificate validation common processing unit 53 (s303).

[0074] (OCSP request) 14 is a diagram showing an example of the data format of an OCSP request 700. The OCSP request 700 has information fields: an OCSP basic field 701 in which basic information of the validation request is set, and an OCSP extension field 702 in which extended information of the validation request is set. The OCSP basic field 701 holds basic information content 703 (e.g., information conforming to the provisions of RFC2560). The OCSP extension field 702 holds information 704 of the certificate to be validated (in this embodiment, an X.509 certificate). The OCSP extension field 702 also optionally includes information 705 of a trust anchor (anchor point) in the bridge model (in this embodiment, an X.509 certificate). The trust anchor information 705 is information added by the person to be validated when the certificate to be validated is used in the bridge model.

[0075] Next, as shown in FIG. 13, the certificate validation common processing unit 53 executes a bridge model validation process in s305 to s313 to validate the certificate to be validated based on the bridge model.

[0076] First, as shown in s305, the certificate validation common processing unit 53 determines whether or not a bridge model trust anchor is set in the acquired OCSP request 700. Specifically, the certificate validation common processing unit 53 determines whether or not trust anchor information 705 is set in the OCSP extension field 702 of the OCSP request 700.

[0077] If a bridge model trust anchor is set in the OCSP request 700 (s305: Yes), the certificate validation common processing unit 53 executes the process of s307, and if a bridge model trust anchor is not set in the OCSP request 700 (s305: No), the certificate validation common processing unit 53 executes the process of s315.

[0078] In s307 and s309, the certificate validation common processing unit 53 searches the certificate store 100 to determine whether the trust anchor information of the validation request is registered. For example, the certificate validation common processing unit 53 refers to each record in the certificate management table 110 and checks whether there is a record in which the trust anchor information 705 included in the validation request corresponds to the subject name 113, subject key identifier 114, and serial number 115 in the certificate management table 110.

[0079] If the trust anchor information of the validation request is registered in the certificate store 100 (s309: Yes), the certificate validation common processing unit 53 executes the process of s311, and if the trust anchor information of the validation request is not registered in the certificate store 100 (s309: No), the certificate validation common processing unit 53 executes the process of s313.

[0080] The certificate validation common processing unit 53 also executes the process of s313 when the "bridge model" is not specified in the trust model 116 of the record related to the certificate to be validated in the certificate management table 110.

[0081] In s313, the certificate validation common processing unit 53 creates an OCSP response (information indicating the result of validity verification of the certificate to be certified included in the OCSP request 700) containing error information indicating that the trust anchor information of the validation request is not registered in the certificate store 100, and then performs processing in s327.

[0082] In s311, the certificate validation common processing unit 53 invokes the construction and verification process s311 to construct a linkage (certification path) between each certification authority (certificate) from the verifier (certificate) to the subject of verification (certificate) based on the verifier's trust anchor (hereinafter referred to as a bridge model trust anchor) indicated in the OCSP request 700, verify the validity of each certificate in the certification path, and create an OCSP response. The construction and verification process s311 will be described in detail later. Thereafter, the certificate validation common processing unit 53 performs the process of s327.

[0083] In the process of s315 to s325, the certificate validation common processing unit 53 executes a trust list validation process for validating the validation target certificate using the trust list. That is, in s315 and s317, the certificate validation common processing unit 53 references the certificate store 100 and attempts to acquire information about the trust anchor certificate (CA certificate) and the CA certificate of the higher-level certification authority that has a trust relationship with the certification authority associated with that trust anchor. The certificate validation common processing unit 53 checks whether those CA certificates are registered in a trust list and the country name (TL management country) on that trust list.

[0084] Specifically, the certificate validation common processing unit 53 searches each record in the certificate management table 110 using the issuer of the certificate to be validated as a search key, and acquires the contents of each record that is found in the search. The certificate validation common processing unit 53 also checks whether the acquired record is listed in the TL 117 and the country name 118.

[0085] If the CA certificate is registered in the certificate store 100 (s317: Yes), the certificate The validation common processing unit 53 executes the process of s319, and if the CA certificate is not registered in the certificate store 100 (s317: NO), the certificate validation common processing unit 53 executes the process of s323.

[0086] The certificate validation common processing unit 53 also executes the process of s323 when the "trusted list" is not specified in the trust model 116 of the record related to the certificate to be validated in the certificate management table 110.

[0087] In s323, the certificate validation 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 of s327.

[0088] In s319, the certificate validation common processing unit 53 invokes the construction and validation process s311, and based on the CA certificate (hereinafter referred to as the server-configured trust anchor) obtained (searched) in s315, constructs a linking relationship (certification path) between each certificate (certification authority) from the server-configured trust anchor to the certificate to be validated, and verifies the validity of each certificate in that certification path.

[0089] Next, the certificate validation common processing unit 53 determines whether the certificate included in the OCSP request 700 is registered in the trust list (s321).

[0090] If the certificate indicated by the OCSP request 700 is registered in the trust list (s321: Yes), the certificate validation common processing unit 53 executes the additional processing s325 described below, and if the certificate indicated by the OCSP request 700 is not registered in the trust list (s321: No), the certificate validation common processing unit 53 executes the processing of s327.

[0091] In s327, the certificate validation common processing unit 53 passes the created OCSP response to the validation result response unit 52. The validation result response unit 52 creates a validation response, which is data corresponding to the validation request, by adding predetermined header information, etc. to the received OCSP response, and passes the created validation response to the validation request receiving unit 51. The validation request receiving unit 51 sends the received validation response to the validation requester terminal 10 (s329).

[0092] (OCSP response) 15 is a diagram showing an example of the data format of an OCSP response 800. The OCSP response 800 has an information field: an OCSP basic field 801 in which basic information of the validation response is set, and an OCSP extension field 802 in which extended information of the validation response is set. The OCSP basic field 801 holds basic information content 803 (e.g., information conforming to the provisions of RFC2560). The OCSP extension field 802 holds information about the validation result of the target certificate (result code 804). Furthermore, if trust anchor information is not set in the validation request but a trust anchor is set on the server side (server-set trans-anchor), the OCSP extension field 802 holds a certificate 805 of that trust anchor. Furthermore, the OCSP extension field 802 holds validation information 806 created when the additional process s325 is executed. Here, the addition process s325 will be described in detail.

[0093] <Additional processing> FIG. 16 is a diagram for explaining the details of the addition process s325.

[0094] The TL method verification addition processing unit 54 verifies the TL path of the trust list by referring to the TL management store 200 (s401). Specifically, the TL method verification addition processing unit 54 The TL path management table 230 is referenced to check whether or not there is a record of a TL path that has the starting point TL that has already been set (s101) as the starting point of the TL path and the issuer of the certificate to be verified in the validation request as the end point of the TL path.

[0095] Furthermore, the TL method verification additional 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 additional processing unit 54 verifies the validity of each trust list by referring to the TL management table 210 and the issue date and time 213 and the next update date and time 214 of the record in which the scheme name of each TL in the TL path identified in s401 is set in the TL scheme name 212.

[0096] Furthermore, the TL method verification additional processing unit 54 verifies the quality of each trust list in the TL path identified in s401 (s405) by referring to the TL management store 200. Specifically, the TL method verification additional processing unit 54 refers to the TSP management table 250 and acquires the service information extension 255 of the record in which the service name of the certificate authority in each trust list of the TL path identified in s401 is set in the service name 253.

[0097] Then, the TL method validation addition processing unit 54 creates validation data (validation report) that integrates the validation details from s401 to s405 (s407). The TL method validation addition processing unit 54 adds the created validation data to the OCSP response 800 as a part of the OCSP response (s409). If the validation fails in any of s401 to s405, the TL method validation addition processing unit 54 adds error information indicating that the validation fails to the OCSP response 800 as a part of the OCSP response 800. Next, the construction and verification process s111 will be described in detail.

[0098] <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.

[0099] The certificate validation common processing unit 53 acquires the CA certificate of the certificate authority that issued the certificate to be validated from the certificate authority server 20 (s501).

[0100] The certificate validation 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 validation 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 validation common processing unit 53 executes the process of s505.

[0101] In s505, the certificate validation common processing unit 53 references the CA certificate currently being acquired to acquire the CA certificate of the higher-level certification authority of the CA certificate in question, and then repeats the process of s503.

[0102] In s507, the certificate validation common processing unit 53 determines whether the self-signed certificate (signer's trans-anchor) identified in s503 matches the trust anchor (bridge model trust anchor or server-configured trust anchor).

[0103] If the self-signed certificate identified in s503 matches the trust anchor (s507: Yes), the certificate validation common processing unit 53 executes the process of s513, and if the self-signed certificate identified in s503 does not match the trust anchor (s507: No), the certificate validation common processing unit 53 executes the process of s509. When performing the validation process on the intermediate CA certificate, the certificate validation common processing unit 53 performs the processes of S503 and S505 up to the highest intermediate CA certificate, and then performs the processes from S507 onwards.

[0104] In s509, the certificate validation common processing unit 53 obtains the cross-certification certificate issued by the trans-anchor (certification authority) of the verifier indicated in the OCSP request 700 to another certification authority that performed cross-certification, from a repository such as the TL public site 30.

[0105] Furthermore, the certificate validation common processing unit 53 acquires from the repository of the certification authority the mutual authentication certificate issued by the other certification authority to the transanchor of the signer, which is yet another certification authority with which mutual authentication has been performed (s511).

[0106] The certificate validation common processing unit 53 stores each certificate from the verifier's trust anchor (certificate authority) to the certificate to be validated, which was identified in s509 and s511, as a certification path (s513).

[0107] Although the case where a certification path is constructed by three mutually certified certification authorities has been described here, the same processing is performed when a certification path is constructed by four or more certification authorities.

[0108] 18 is a flow diagram illustrating the process related to the verification of the certification path (verification of the validity of the certificate) in the construction and verification process s111. This process is performed following the process up to s513.

[0109] The certificate validation common processing unit 53 arranges each "certificate x" (s601) so that for each certificate x of the certification path constructed by the processing up to s513, the certificate of the verifier's transanchor (certificate authority) which is the starting point is "certificate 1", the certificate to be validated which is the end point is certificate n (n: the total number of certificates) and the subject of authentication in "certificate x" (x: 1 to n) is the issuer name of the certificate in "certificate x+1".

[0110] The certificate validation common processing unit 53 verifies that the verification time (for example, the current time) of each "certificate x" sorted in s601 is the expiration date of "certificate x." If the certificate validation common processing unit 53 detects a certificate whose verification time is not the expiration date, it may generate error information as the OCSP response 800.

[0111] The certificate validation common processing unit 53 sets the target "certificate x" to "certificate 2" (s605).

[0112] The certificate validation common processing unit 53 confirms that the "certificate x" being processed has been signed with a private key corresponding to the public key of "certificate x-1" (s607). If "certificate x" has not been signed with a private key corresponding to the public key of "certificate x-1", the certificate validation common processing unit 53 may generate error information as the OCSP response 800.

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

[0114] If the "certificate x" to be processed is "certificate n" (s611: yes), the certificate validation common processing unit 53 executes the processing of s613, and if the "certificate x" to be processed is not "certificate n" (s611: yes), the certificate validation common processing unit 53 repeats the processing from s607 onwards.

[0115] In s613, the certificate validation common processing unit 53 verifies that each "certificate x" has not been revoked. For example, the certificate validation common processing unit 53 acquires revocation information from each certification authority server 20, and verifies that each "certificate x" has not been revoked based on the acquired revocation information. Note that if there is a revoked certificate, the certificate validation common processing unit 53 may generate error information as the OCSP response 800.

[0116] The certificate validation common processing unit 53 refers to the extension area of ​​each "certificate x" and executes processing in accordance with the information (KeyUsage, predetermined policy) set in the extension area (s615). This processing may be omitted. This completes the processing related to the construction of a certification path.

[0117] As described above, the certificate validation server 50 of this embodiment stores, based on the information of multiple trust lists received from the TL disclosure site 30, information on the connection relationships between the trust lists and the validity of each trust list (TL management table 210 and TL path management table 230), as well as information on the certification authorities registered in the trust lists whose connection relationships and validity have been confirmed (TSP management table 250 and certificate management table 110).When a validation request is received from the validation requester terminal 10, the server transmits to the validation requester terminal 10 a validation response that verifies the connection relationships between the certification authorities of the certificate to be verified and the trust anchor and the validity of the certificates of each certification authority, based on the certificate information (trust anchors) of the certification authorities identified from each database.

[0118] In this way, the certificate validation server 50 of this embodiment stores, as a trust anchor, the certificate of a TL for which construction of multiple TL paths and verification of each certificate in the TL path (signature verification) have been successful, and can use that trust anchor to verify the certificate to be validated. In other words, according to the certificate validation server 50 of this embodiment, even when multiple trust lists exist, certificate validation can be performed based on a highly reliable trust anchor.

[0119] In addition, the certificate validation server 50 of this embodiment executes a trust list validation process if the validation request does not include a trust anchor, and if the validation request includes a trust anchor, constructs and validates an authentication path based on the certificate to be validated and its trust anchor, and performs validation using the bridge model.

[0120] This allows the certificate validation server 50 to automatically determine the validation method to be used for certificate validation, even if the certificate does not support TL and only supports the Bridge Model.

[0121] Furthermore, the certificate validation server 50 of this embodiment repeatedly executes the trust list acquisition process at timings preset in the update setting value information 270 .

[0122] In this way, by constantly acquiring TL information, the processing load for constructing and verifying a TL path can be reduced, and the accuracy of certificate verification can be improved.

[0123] In addition, the certificate validation server 50 of this embodiment stores the certificates of the certification authorities registered in the trust list whose linkage and validity have been confirmed in the certificate management table 110, and if the validation request does not include a trust anchor, performs trust list validation processing based on the information (trust anchor) of the certification authority certificate registered in the certificate management table 110.

[0124] In this way, by verifying the certificates using the trust list using the certificate management table 110 in which only trust lists whose linkages and validity have been confirmed are registered, the trust Highly reliable verification can be performed.

[0125] In addition, the certificate validation server 50 of this embodiment accepts input from the user of the validation method supported by the certificate to be validated (trust model 116 of the certificate management table 110), and when a validation request is received, executes the trust list validation process only if the trust model 116 specifies a certificate validation method using a trust list.

[0126] This allows the certificate to be verified in accordance with the verification method supported by the certificate to be verified.

[0127] In addition, when the certificate validation server 50 of this embodiment executes the trust list validation process, it creates a validation report of the trust list for which the TL path has been constructed and validated, and sends a validation response including the validation report to the validation requester terminal 10.

[0128] This allows the reliability of the trust list to be improved by providing the verification requester terminal 10 with information on the quality of the certificates in the trust list, such as QC / QSCD judgments.

[0129] The present invention is not limited to the above-described embodiments, and can be implemented using any components within the scope of the gist of the present invention. The above-described embodiments and modifications are merely examples, and the present invention is not limited to these contents as long as the features of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of ​​the present invention are also included within the scope of the present invention.

[0130] For example, some of the functions provided 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.

[0131] Furthermore, the program configuration described in this embodiment is an example, and for example, a part of a program may be incorporated into another program, or multiple programs may be configured as a single program. [Explanation of symbols]

[0132] 1 Certificate Validation System 10 Verification requester terminal 50 Certificate Validation Server

Claims

1. a processor and a memory, the processor a store management process that executes a trust list acquisition process that acquires, based on information on a plurality of trust lists received from a first information processing device, information on link relationships between the plurality of trust lists and validity of the plurality of trust lists, and information on certificate authorities registered in the trust lists whose link relationships and validity have been confirmed, and stores the information in the memory; a certificate verification common process for executing a trust list verification process, when a verification request including a certificate to be verified is received from a second information processing device, to verify a connection relationship between the certificate authority indicated by the certificate to be verified and the specified certificate authority, and the validity of the certificate of each of the certificate authorities, based on information on the certificate of the certificate authority identified from the information stored in the memory; a verification result response process of transmitting the verification result to the second information processing device; A certificate verification device that performs the above.

2. In the common certificate verification process, the processor determining whether or not the received verification request is accompanied by a trust anchor, which is a certificate trusted by the verifier, and if the verification request is not accompanied by the trust anchor, executing the trust list verification process; If the trust anchor is attached to the validation request, a bridge model validation process is executed based on the certificate to be validated and the trust anchor to validate the connection between the certificate authority identified by the certificate to be validated and the certificate authority indicated by the trust anchor, and the validity of the certificate of each of the certificate authorities, and the validation results are sent to the second information processing device. The certificate verification device according to claim 1 .

3. The processor: The certificate validation device according to claim 1 , wherein the store management process repeatedly executes the trust list acquisition process at preset timings.

4. The processor: In the store management process, the certificate of the certification authority registered in the trust list whose connection relationship and validity have been confirmed is stored in the memory; In the common certificate validation process, if the received validation request does not include a trust anchor, the trust list validation process is executed based on information about certificates of certification authorities registered in a trust list whose connection relationship and validity have been confirmed and stored in the memory. The certificate verification device according to claim 2 .

5. further comprising an input device; The processor: receiving, from a user, an input of a verification method supported by the certificate to be verified by the input device; In the common certificate validation process, when the validation request is received, it is determined whether or not the input validation method specifies a method of validating the certificate using the trust list, and only if the input validation method specifies a method of validating the certificate using the trust list, the trust list validation process is executed. The certificate verification device according to claim 1 .

6. The processor: execute a TL method verification addition process to create 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; In the verification result response process, the verification result including the created information is transmitted to the second information processing device. The certificate verification device according to claim 1 .

7. An information processing device including a processor and a memory, wherein the processor: a store management process that executes a trust list acquisition process that acquires, based on information on a plurality of trust lists received from another first information processing device, information on connection relationships between the plurality of trust lists and validity of the plurality of trust lists, and information on certificate authorities registered in the trust lists whose connection relationships and validity have been confirmed, and stores the information in the memory; a certificate verification common process for executing a trust list verification process, when a verification request including a certificate to be verified is received from another second information processing device, to verify a connection relationship between the certificate authority indicated by the certificate to be verified and the specified certificate authority and the validity of the certificate of each of the certificate authorities, based on information on the certificate of the certificate authority identified from the information stored in the memory; a verification result response process of transmitting the verification result to the second information processing device; The certificate validation method to perform.

8. the processor: In the common certificate verification process, it is determined whether or not the received verification request is accompanied by a trust anchor, which is a certificate trusted by the verifier, and if the verification request is not accompanied by the trust anchor, it executes the trust list verification process; If the trust anchor is attached to the validation request, a bridge model validation process is executed based on the certificate to be validated and the trust anchor to validate the connection between the certificate authority identified by the certificate to be validated and the certificate authority indicated by the trust anchor, and the validity of the certificate of each of the certificate authorities, and the validation results are sent to the second information processing device. The certificate verification method according to claim 7.

9. the processor: The certificate validation method according to claim 7 , wherein the trust list acquisition process is repeatedly executed at preset timings in the store management process.

10. the processor: In the store management process, the certificate of the certification authority registered in the trust list whose connection relationship and validity have been confirmed is stored in the memory; In the common certificate validation process, if the received validation request does not include a trust anchor, the trust list validation process is executed based on information about certificates of certification authorities registered in a trust list whose connection relationship and validity have been confirmed and stored in the memory. The certificate verification method according to claim 8.

11. 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 by the input device; In the common certificate verification process, when the verification request is received, it is determined whether or not the input verification method specifies a method of verifying the certificate using the trust list, and if the input verification method specifies a method of verifying the certificate using the trust list, and performing the trust list verification process only if The certificate verification method according to claim 7.

12. the processor: When executing the trust list verification process, a TL method verification addition process is executed to create information indicating the quality of the trust list related to the certificate authority whose connection relationship and validity have been verified based on the information stored in the memory; In the verification result response process, the verification result including the created information is transmitted to the second information processing device. The certificate verification method according to claim 7.

13. An information processing device including a processor and a memory, a store management process that executes a trust list acquisition process that acquires, based on information on a plurality of trust lists received from another first information processing device, information on connection relationships between the plurality of trust lists and validity of the plurality of trust lists, and information on certificate authorities registered in the trust lists whose connection relationships and validity have been confirmed, and stores the information in the memory; a certificate verification common process for executing a trust list verification process, when a verification request including a certificate to be verified is received from another second information processing device, to verify a connection relationship between the certificate authority indicated by the certificate to be verified and the specified certificate authority and the validity of the certificate of each of the certificate authorities, based on information on the certificate of the certificate authority identified from the information stored in the memory; a verification result response process of transmitting the verification result to the other second information processing device; A program that executes the following.

14. 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; a processor and a memory, the processor a store management process that executes a trust list acquisition process that acquires, based on information on a plurality of trust lists received from the first information processing device, information on connection relationships between the plurality of trust lists and validity of the plurality of trust lists, and information on certificate authorities registered in the trust lists whose connection relationships and validity have been confirmed, and stores the information in the memory; a certificate verification common process that, when receiving a verification request including a certificate to be verified from the second information processing device, executes a trust list verification process that verifies, based on information on the certificate of the certificate authority identified from the information stored in the memory, a connection relationship between the certificate authority indicated by the certificate to be verified and the identified certificate authority, and the validity of the certificate of each of the certificate authorities; a certificate verification device that executes a verification result response process to transmit the verification result to the second information processing device; A certificate validation system comprising:

Images