Verification method and verification system

Abstract

This invention provides a verification method and system that enable secure and easy certificate authentication when two devices use different encryption methods. [Solution] The verification method of the embodiment is a verification method performed in a verification system comprising a first entity that uses a first self-signed certificate issued by a first root CA and a second entity that uses a second self-signed certificate issued by a second root CA, wherein the second entity obtains a second digital certificate issued based on the second self-signed certificate, the first entity obtains the second digital certificate from the second entity, verifies the obtained second digital certificate with the first self-signed certificate it stores, and if the first self-signed certificate cannot authenticate the second digital certificate, the first self-signed certificate authenticates the obtained second digital certificate based on information that the first self-signed certificate trusts the second self-signed certificate and the second digital certificate.

Description

Technical Field

[0001] Embodiments of the present invention relate to a verification method and a verification system.

Background Art

[0002] When data is transmitted and received between two devices (computer devices) via a network communication network, in order to protect the data from others, for example, encrypted data using a certificate is transmitted and received.

[0003] There are various encryption methods, which are used appropriately according to the scene and application, such as the processing speed of the device and the level of security. However, at least some of the currently used encryption methods may be decoded by the advent of quantum computers, and new encryption methods are being studied as a solution.

[0004] Specifically, in recent years, as a new encryption method, research, development, and practical application of PQC (Post-Quantum Cryptography, quantum-resistant computer cryptography), which is an encryption that can maintain security even when a sufficiently large-scale quantum computer is put into practical use, have been promoted.

[0005] On the other hand, regarding the change to a new encryption method, there are cases where it cannot be changed due to restrictions on the software and hardware of the device, or where it is realistically difficult to change immediately because the life cycle of the device is long.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0007] As mentioned above, due to changes in encryption methods, if two devices use different encryption methods, it may not be possible to securely verify certificates due to these differences.

[0008] Therefore, the problem that the present invention aims to solve, in view of the above circumstances, is to provide a verification method and a verification system that can safely and easily verify certificates even when two devices use different encryption methods. [Means for solving the problem]

[0009] The verification method of the embodiment is a verification method performed in a verification system comprising a first entity that uses a first self-signed certificate issued by a first root CA and a second entity that uses a second self-signed certificate issued by a second root CA, wherein the second entity obtains a second digital certificate issued based on the second self-signed certificate, the first entity obtains the second digital certificate from the second entity, verifies the obtained second digital certificate with the first self-signed certificate it stores, and if the first self-signed certificate cannot authenticate the second digital certificate, the first self-signed certificate authenticates the obtained second digital certificate based on information that the first self-signed certificate trusts the second self-signed certificate and the second digital certificate. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 shows an example of the configuration of the verification system according to the embodiment. [Figure 2] Figure 2 is a diagram illustrating the correspondence between the verification systems of the embodiment. [Figure 3] Figure 3 is a block diagram showing an example of the functional configuration of the first entity of the embodiment. [Figure 4] Figure 4 is a block diagram showing an example of the hardware configuration of the first entity in the embodiment. [Figure 5] Figure 5 shows an example of the transaction data structure in the embodiment. [Figure 6] Figure 6 is a flowchart showing an example of processing by the first entity of the embodiment. [Modes for carrying out the invention]

[0011] The verification system and verification method of this embodiment will be described below with reference to the attached drawings.

[0012] Figure 1 shows an example configuration of the verification system 3 of the embodiment. The verification system 3 comprises a first root CA (certificate authority) 1, a second root CA 2, a first entity (client device) 100, a second entity (client device) 200, and a blockchain system 4. The verification system 3 is connected via a network N for communication. Details will be explained using Figure 2.

[0013] Figure 2 is a diagram illustrating the correspondence of the verification system 3 of the embodiment. As shown in Figure 2, the verification system 3 comprises a first entity 100 (100-1 to 100-N), a first intermediate CA 10 (10-1 to 10-N), a first root CA 1, a second entity 200 (200-1 to 200-N), a second intermediate CA 20 (20-1 to 20-N), a second root CA 2, and a blockchain system 4.

[0014] The first root CA1 is a certificate authority that issues the top-level self-signed certificate (root certificate). The first root CA1 sends the first root certificate (first self-signed certificate) to the first intermediate CA10 and the first entity 100.

[0015] The first intermediate CA10 is a certificate authority excluding the first root CA1. The first intermediate CA10 is a certificate authority that issues the first intermediate certificate guaranteed by the first root certificate. The first intermediate CA10 sends the first intermediate certificate to the first entity 100.

[0016] The first entity 100 stores a first root certificate issued by the first root CA1 and a first intermediate certificate issued by the first intermediate CA10. Similarly, a plurality of first entities 100-1 to 100-N also store the first root certificate and the first intermediate certificate. The first entity 100 is, for example, an example of the first device. For the sake of explanation, the first entity 100 is, for example, a device that only supports existing cryptographic methods (such as RSA cryptography, elliptic curve cryptography, etc.).

[0017] Next, the second root CA2 is, for example, a certification authority different from the first root CA1 that issues a self-certificate as the top-level certificate. The second root CA2 transmits a second root certificate (second self-certificate) to the second intermediate CA20 and the second entity 200.

[0018] The second intermediate CA20 is a certification authority other than the second root CA2. The second intermediate CA20 is a certification authority that issues a second intermediate certificate guaranteed by the second root certificate. The second intermediate CA20 transmits the second intermediate certificate to the second entity 200.

[0019] The second entity 200 stores a second root certificate issued by the second root CA2 and a second intermediate certificate issued by the second intermediate CA20. Similarly, a plurality of second entities 200-1 to 200-N also store the second root certificate and the second intermediate certificate. The second entity 200 is, for example, an example of the second device. For the sake of explanation, the second entity 200 is, for example, a device that only supports a new cryptographic method that is one of PQC (Post-Quantum Cryptography).

[0020] Using FIG. 2, an example of the process in which the first entity 100-1 and the first entity 100-2 perform certificate authentication in advance to perform data transmission and reception will be described.

[0021] Since the first entity 100-1 and the first entity 100-2 store the same first root certificate, the case where the certificate authentication is successful is described.

[0022] First, the first entity 100-2 obtains the first server certificate from the first server and stores it. The first server certificate is guaranteed by the first intermediate certificate. When there is a communication access from the first entity 100-1, the first entity 100-2 sends the first server certificate to the first entity 100-1.

[0023] Next, the first entity 100-1 obtains the first server certificate from the first entity 100-2 and verifies the obtained first server certificate with the first root certificate stored by the first entity 100-1.

[0024] When the authentication between the first server certificate and the first root certificate is successful, the first entity 100-1 and the first entity 100-2 can safely send and receive data.

[0025] Note that, similar to the first entity 100-1, the first entity 100-2 also verifies the first server certificate obtained from the first entity 100-1 with the first root certificate stored by the first entity 100-2. When the authentication is successful, they can safely send and receive data with each other.

[0026] Next, for example, the process of pre-authenticating certificates for the first entity 100-1 and the second entity 200-1 to send and receive data is described.

[0027] Here, since the first entity 100-1 and the second entity 200-1 store different certificates, namely the first root certificate and the second root certificate respectively, the case where the certificate authentication fails is described.

[0028] The second entity 200-1 obtains and stores the second server certificate from the second server. The second server certificate is guaranteed by the second intermediate certificate. The second entity 200-1 sends the second server certificate when there is a communication access from the first entity 100-1.

[0029] The first entity 100-1 obtains a second server certificate from the second entity 200-1 and verifies the obtained second server certificate using the first root certificate stored by the first entity 100-1.

[0030] The second server certificate is guaranteed by the second intermediate certificate. The second intermediate certificate is guaranteed by the second root certificate. In other words, since the second server certificate is not guaranteed by the first root certificate, the first entity 100-1 cannot authenticate the second server certificate using the first root certificate it stores, and the authentication fails.

[0031] Next, we will explain how the verification system 3 according to the embodiment handles cases where authentication fails, for example, because the entities use different encryption methods.

[0032] If authentication fails, the first entity 100-1 retrieves the transaction from the block on blockchain system 4. Blockchain system 4 will be described later.

[0033] The transaction stores digitally signed trust information data, for example, that the first root CA1 trusts the second root CA2, and that the second root CA2 trusts the certificates containing the second root certificate (second intermediate certificate, second server certificate) issued by the second root CA2.

[0034] The above trust information can be used by the first entity 100-1 to authenticate the second server certificate. In the case of authentication failure due to different cryptographic schemes between entities, the verification system 3 according to the embodiment uses the trust information contained in the transaction of the block of the blockchain system 4 to easily and securely switch the certificate for authentication.

[0035] Next, the functional configuration of the first entity 100 of the embodiment will be described. Figure 3 is a block diagram showing an example of the functional configuration of the first entity 100 of the embodiment. As shown in Figure 3, the first entity 100 includes a communication unit 101, an acquisition unit 102, a storage unit 103, a verification unit 104, and an output unit 105.

[0036] The communication unit 101 is connected to the network N and can communicate with multiple first entities 100, second entities 200, etc. It can also access the blockchain system 4. In addition, it can communicate with the first root CA1, the first intermediate CA, etc.

[0037] The acquisition unit 102 acquires, for example, server certificates from other first entities 100 and second entities 200. It also acquires trust information and the like written to transaction 5 from the blockchain system 4.

[0038] The storage unit 103 stores the data acquired by the acquisition unit 102. It stores certificates. For example, it stores the first root certificate.

[0039] The verification unit 104 verifies the stored certificate against the certificate to be obtained. For example, it verifies the first root certificate stored in the storage unit 103 against the obtained server certificate. The verification unit 104 performs the verification and determines whether the authentication is successful or unsuccessful.

[0040] Furthermore, if authentication fails, the verification unit 104 verifies the acquired server certificate based on the trust information written to the transaction.

[0041] The output unit 105 outputs, for example, the authentication result from the verification unit 104. The output unit 105 is an information output means and is composed of, for example, a display device, an audio output device (an output unit that outputs audio), etc.

[0042] Note that Figure 3 uses the first entity 100 as an example. The second entity 200 has a similar configuration.

[0043] Next, the hardware configuration of the first entity 100 of the embodiment will be described. Figure 4 is a block diagram showing an example of the hardware configuration of the first entity 100 of the embodiment. As shown in Figure 4, it includes a control device such as a CPU 111, storage devices such as a ROM (Read Only Memory) 112 and a RAM (Random Access Memory) 113, a communication I / F (Interface) 114 for communication via a network, a user I / F 115, and a bus 116 for connecting each part.

[0044] The program executed by the verification system 3 according to this embodiment is provided pre-installed in the ROM 112 or the like.

[0045] The program executed by the verification system 3 according to this embodiment may be configured to be provided as a computer program product by recording it as an installable or executable file on a computer-readable recording medium such as a CD-ROM (Compact Disk Read Only Memory), a flexible disk (FD), a CD-R (Compact Disk Recordable), or a DVD (Digital Versatile Disk).

[0046] Furthermore, the program executed by the verification system 3 according to this embodiment may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. Alternatively, the program executed by the verification system 3 according to this embodiment may be provided or distributed via a network such as the Internet.

[0047] The program executed in the verification system 3 according to this embodiment can cause the computer to function as one of the components of the verification system 3 described above. This computer can read the program from a computer-readable storage medium into its main memory and execute it using its CPU.

[0048] The user interface 115 is a device that enables the exchange of information between the first entity 100 and the second entity 200 and the user, and may be, for example, a display, keyboard, pointing device, touch panel mechanism, speaker, microphone, etc.

[0049] Figure 4 illustrates the first entity 100 as an example. The second entity 200 has a similar configuration.

[0050] Next, the data structure of the transaction in the embodiment will be described. Figure 5 is a diagram showing an example of the data structure of transaction 5 in the embodiment. As shown in Figure 5, the blockchain system 4 has a structure in which multiple blocks 40 are linked together.

[0051] Block 40 (40-1 to 40-N) generates a block hash that incorporates the hash 41 of the transaction immediately preceding the corresponding block 40. This creates a data structure where hash calculations are linked together in a chain-like fashion. As a result, the entire chain is tamper-proof, preventing legitimate transactions from being overwritten later.

[0052] Block 40 is data that includes at least the hash 41 (41-1 to 41-N) of the previous transaction, transaction 5 (5-1 to 5-N), and the nonce (number used once) 42 (42-1 to 42-N).

[0053] Hash 41 is, for example, the data of transaction 5 from the previous block 40, converted into a fixed-length string. Nonce 42 is a number that identifies block 40.

[0054] Transaction 5 is, for example, data that has been digitally signed by one of several root CAs.

[0055] Transaction 5 described above is, for example, digitally signed by the first root CA1 using the first root CA1's private key. Therefore, the first entity 100 can authenticate transaction 5 recorded by the first root CA1 using the first root certificate owned by the first entity 100, and thus can trust transaction 5 written by the first root CA1.

[0056] Figure 6 is a flowchart illustrating an example of processing by the first entity 100 in the embodiment. For example, the process by which the first entity 100 authenticates the second server certificate of the second entity 200 will be explained using the flowchart.

[0057] As shown in Figure 6, the first entity 100 performs certificate authentication in advance in order to communicate with the second entity 200. The first entity 100 stores the first root certificate issued by the first root CA1. The first entity 100 requests communication access from the second entity 200 (step S1).

[0058] The second entity 200 stores the second root certificate issued by the second root CA2. It also stores the second server certificate issued based on the second root certificate. The second entity 200 receives an access request from the first entity 100 and sends the second server certificate to the first entity 100 (step S2).

[0059] The first entity 100 verifies the acquired second server certificate using the first root certificate stored in the storage unit 103 (step S3).

[0060] One verification method is to check whether the hash value of the second server certificate matches the hash value of the first root certificate.

[0061] The first entity 100 determines whether the authentication of the second server certificate was successful or unsuccessful based on the first root certificate (step S4).

[0062] If authentication is successful for the first entity 100 (step S4; Yes), it proceeds to step S8. Note that the example shown is the case where the second server certificate is verified by the first root certificate, so authentication fails. However, if, for example, two first entities 100 verify the first server certificate using the first root certificate, authentication will be successful.

[0063] Next, if authentication fails (Step S4; No), the first entity 100 checks whether the first intermediate CA 10 and the first root CA 1 have trust information that trusts the second root CA 2 (Step S5).

[0064] If verification information for the second root CA2 can be obtained from the first intermediate CA10 and the first root CA1 in step S5, the second server certificate may be verified based on that information.

[0065] If, in step S5, the first intermediate CA10 and the first root CA1 do not have trust information to trust the second root CA2, the first entity 100 retrieves transaction 5 from block 40 of blockchain system 4 (step S6).

[0066] Transaction 5 stores digitally signed data indicating, for example, that the first root CA1 trusts the second root CA2, and that the second root CA2 trusts the certificates containing the second root certificate (second intermediate certificate, second server certificate) issued by the second root CA2.

[0067] Transaction 5 is recorded by the first root CA1. The first entity 100 can authenticate transaction 5 recorded by the first root CA1 using its own first root certificate. Therefore, it can trust transaction 5 written by the first root CA1.

[0068] The first entity 100 verifies the second server certificate based on the trust information that the first root CA1 included in transaction 5 trusts the second server certificate (step S7).

[0069] The first entity 100 may determine that the authentication of the second server certificate is successful based on the trust information contained in transaction 5, and the output unit 105 may indicate that the authentication was successful (step S8).

[0070] The second entity 200, the communication destination, also performs the processes from step S1 to step S8 described above. If the second entity 200 is able to authenticate the first server certificate of the first entity 100, they can communicate with each other (step S9).

[0071] If the second entity 200, as described in step S9, authenticates, then for example, transaction 5 stores digitally signed data indicating that the second root CA2 trusts the first root CA1 and trusts the certificates issued by the first root CA1, including the first root certificate (first intermediate certificate, first server certificate).

[0072] The second entity 200 verifies the first server certificate based on the trust information contained in transaction 5, which indicates that the second root CA2 trusts the first server certificate. This results in successful authentication of the first server certificate based on the trust information contained in transaction 5.

[0073] Thus, for example, in a transitional period when cryptographic methods are being switched, even if the entities have different self-signed certificates, the certificate can be authenticated by a transaction on the blockchain system 4.

[0074] Furthermore, as a variation, let's explain the modification (rewriting) of a transaction. For example, let's assume that the first root CA1 is the PQC encryption scheme, and the second root CA2 is an existing encryption scheme.

[0075] When the encryption method is switched, if the first entity 100 restricts the second digital certificate of the second entity 200, the first root CA1 rewrites the trust information of transaction 5. Specifically, the trust information "the first root CA1 trusts the second root CA2" is rewritten to "the first root CA1 does not trust the second root CA2". Note that the first entity 100 may rewrite the trust information of transaction 5, or the first entity 100 may instruct the first root CA1 to rewrite the trust information. Note that transaction 5 may also be rewritten by the administrator of the blockchain system 4.

[0076] This allows access to the existing encryption method to be restricted after the encryption method has been switched. Therefore, the encryption method can be switched securely.

[0077] According to at least one verification method of this embodiment described above, in a verification system comprising a first entity that uses a first self-signed certificate issued by a first root CA and a second entity that uses a second self-signed certificate issued by a second root CA, the verification method is performed between the first entity and the second entity, wherein the second entity obtains a second digital certificate issued based on the second self-signed certificate, the first entity obtains the second digital certificate from the second entity, verifies the obtained second digital certificate using the first self-signed certificate it stores, and if the first self-signed certificate cannot authenticate the second digital certificate, the first entity authenticates the obtained second digital certificate based on information that the first self-signed certificate trusts the second self-signed certificate and the second digital certificate.

[0078] This allows authentication to be performed based on trust information if authentication fails using a stored self-signed certificate when verifying certificates with different encryption methods. Therefore, authentication can be performed even when different entities use different encryption methods, such as during transitional periods when encryption methods are switched. For example, authentication can be easily and securely performed based on trust information without distributing self-signed certificates with different encryption methods.

[0079] Furthermore, according to the verification method of this embodiment, the first entity obtains a transaction from the blockchain system that includes information that the first self-signed certificate trusts the second self-signed certificate and trusts the second digital certificate.

[0080] This allows for secure authentication by using trust information that is difficult to tamper with or alter in the blockchain system.

[0081] Furthermore, according to the verification method of this embodiment, if the first entity restricts the second digital certificate of the second entity, it overwrites the information that the first self-signed certificate of the transaction trusts the second self-signed certificate to information that the first self-signed certificate does not trust the second self-signed certificate.

[0082] This allows access to the existing encryption method to be restricted after the encryption method has been switched. Therefore, the encryption method can be switched securely.

[0083] According to the verification system of this embodiment, the verification system comprises a first entity that uses a first self-signed certificate issued by a first root CA and a second entity that uses a second self-signed certificate issued by a second root CA, wherein the second entity includes an acquisition unit that acquires a second digital certificate issued based on the second self-signed certificate, the first entity includes an acquisition unit that acquires the second digital certificate from the second entity and a verification unit that verifies the acquired second digital certificate using the first self-signed certificate it stores, and if the first self-signed certificate cannot authenticate the second digital certificate, the verification unit obtains a transaction from the blockchain system using the acquisition unit of the first entity that includes information that the first self-signed certificate trusts the second self-signed certificate and trusts the second digital certificate, and authenticates the acquired second digital certificate based on the transaction.

[0084] Although several embodiments of the present invention have been described above, these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be carried out in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents. [Explanation of symbols]

[0085] 1...First Root CA, 2...Second Root CA, 3...Verification System, 4...Blockchain System, 5...Transaction, 10...First Intermediate CA, 20...Second Intermediate CA, 40...Block, 100...First Entity, 101...Communication Unit, 102...Acquisition Unit, 103...Storage Unit, 104...Verification Unit, 105...Output Unit, 200...Second Entity

Claims

1. A verification method performed in a verification system comprising a first entity that uses a first self-signed certificate issued by a first root CA (certificate authority) and a second entity that uses a second self-signed certificate issued by a second root CA, The second entity obtains a second digital certificate issued based on the second self-signed certificate, The first entity described above is Obtain the second digital certificate from the second entity, The acquired second digital certificate is verified using the first self-signed certificate that is stored, If the second digital certificate cannot be authenticated by the first self-signed certificate, the acquired second digital certificate is authenticated based on the information that the first self-signed certificate trusts the second self-signed certificate and that the second digital certificate trusts the first self-signed certificate. Verification method.

2. The first entity described above is A transaction is obtained from the blockchain system that includes information that the first self-signed certificate trusts the second self-signed certificate and that the second digital certificate trusts the first self-signed certificate. The verification method described in claim 1.

3. The first entity described above is When restricting the second digital certificate of the second entity, the information that the first self-signed certificate trusts the second self-signed certificate is rewritten to information that the first self-signed certificate does not trust the second self-signed certificate. The verification method described in claim 1.

4. In a verification system comprising a first entity that uses a first self-signed certificate issued by a first root CA and a second entity that uses a second self-signed certificate issued by a second root CA, The second entity includes an acquisition unit that acquires a second digital certificate issued based on a second self-signed certificate, The first entity described above is An acquisition unit that acquires the second digital certificate from the second entity, The system includes a verification unit that verifies the acquired second digital certificate using a first self-signed certificate stored in it, The verification unit, If the second digital certificate cannot be authenticated by the first self-signed certificate, Based on the information that the first self-signed certificate trusts the second self-signed certificate and trusts the second digital certificate, the acquired second digital certificate is authenticated. Verification system.

Images