QKDN control device, quantum cryptography communication system, information processing device, QKDN control method, information processing method and program

Abstract

The application keys shared using QKD are optimally distributed to multiple key management devices. [Solution] The QKDN control device of the embodiment includes a processing unit that formulates an allocation plan for distributing application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKD between opposing QKD devices included in the QKDN (Quantum Key Distribution Network), to key management devices connected to each of the multiple applications by a wired communication method or a wireless communication method, based on the amount of application key requests from multiple applications that encrypt or decrypt communications using the application keys.

Description

[Technical Field]

[0001] Embodiments of the present invention relate to a QKDN control device, a quantum cryptography communication system, an information processing device, a QKDN control method, an information processing method, and a program. [Background technology]

[0002] A technique has long been known in which an application uses quantum key distribution (QKD) to obtain random numbers shared with other applications from a key management device, and then uses these random numbers as application keys (encryption keys) to perform encrypted communication with other applications. This encrypted communication by applications takes place on user networks such as the internet, which are different from the QKD network. [Prior art documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2016-171530 [Patent Document 2] Patent No. 6211818 [Non-patent literature]

[0004] [Non-Patent Document 1] ITU-T,Y.3800,“Overview networks on supporting quantum key distribution” 2019 [Non-Patent Document 2] ETSI GS QKD 014,“Quantum Key Distribution (QKD);Protocol and data format of REST-based key delivery API”2019 [Overview of the project] [Problems that the invention aims to solve]

[0005] However, with conventional technology, it was difficult to optimally distribute application keys shared using QKD across multiple key management devices. [Means for solving the problem]

[0006] The QKDN control device of the embodiment includes a processing unit that formulates an allocation plan for distributing application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKD between opposing QKD devices included in the QKDN (Quantum Key Distribution Network), to key management devices connected to each of the multiple applications via a wired or wireless communication method, based on the amount of application key requests from multiple applications that encrypt or decrypt communications using the application keys. [Brief explanation of the drawing]

[0007] [Figure 1] A diagram showing an example of the configuration of a quantum cryptography communication system according to an embodiment. [Figure 2] A diagram showing an example of a quantum cryptography communication network according to an embodiment. [Figure 3] A diagram illustrating an example of sharing application key information in the application, KM, QKDN controller, and QKDN control device of the embodiment. [Figure 4] A diagram showing an example of the functional configuration of the KM in the embodiment. [Figure 5] A diagram showing an example of the functional configuration of the QKDN control device according to the embodiment. [Figure 6] A diagram showing an example of the functional configuration of an information processing device according to an embodiment. [Figure 7] A diagram illustrating an example of application key distribution processing by the QKDN control device of the embodiment. [Figure 8] A diagram showing an example of application key information in an embodiment. [Figure 9] A diagram showing an example of importance information for an embodiment. [Figure 10]Flowchart showing an example of the distribution process of the application key in the embodiment. [Figure 11] Diagram for explaining an example of a method for formulating a distribution plan for the application key in the embodiment. [Figure 12] Diagram showing a specific example 1 of a method for formulating a distribution plan for the application key in the embodiment. [Figure 13] Diagram showing a specific example 2 of a method for formulating a distribution plan for the application key in the embodiment. [Figure 14] Diagram showing a specific example 3 of a method for formulating a distribution plan for the application key in the embodiment. [Figure 15] Diagram showing an example of the functional configuration of KM in a modification of the embodiment. [Figure 16] Diagram showing an example of the hardware configuration of the QKD module in the embodiment. [Figure 17] Diagram showing an example of the hardware configuration of the QKDN control device, information processing device, and KM in the embodiment.

Embodiments for Carrying Out the Invention

[0008] Hereinafter, embodiments of a QKDN control device, a quantum cryptographic communication system, an information processing device, a QKDN control method, an information processing method, and a program will be described in detail with reference to the accompanying drawings.

[0009] A quantum key distribution network (QKDN: Quantum Key Distribution Network) is a network composed of QKD devices and becomes a private network. The QKDN is installed according to the upper-level public user network.

[0010] An application key (hereinafter referred to as "application key") is provided for an application in the upper-level user network, and secure communication is realized. The QKD devices of the QKDN are installed so as to have a provisioning ability corresponding to the required amount of the application key from the application. However, the request for the application key from the application includes a normal case where the request is made regularly or quantitatively, and an emergency case where the application key is suddenly requested.

[0011] Therefore, in order to provide all application key requests from applications in the highest-level user network within the delivery deadline, an optimal distribution of application keys is necessary across the entire QKDN. The optimal distribution of application keys is, for example, an application key distribution plan that specifies which key management device (KM: Key manager) pairs will share how many application keys, and from what time to what time.

[0012] The following embodiment describes a quantum cryptography communication system that enables the formulation of an optimal application key allocation plan.

[0013] First, we will describe the quantum cryptography communication system used in this embodiment.

[0014] Figure 1 shows an example of the configuration of a quantum cryptography communication system according to an embodiment. Viewed from the side, the QKD network architecture consists of a quantum layer, a key management layer, a QKD network control layer, and a QKD network management layer for managing these three layers from bottom to top. These four layers generate application keys used for encrypting and decrypting data communications of application 5 and supply them to the service layer in the top-level user network. Viewed from the top, three nodes 1 (QKD nodes / trusted nodes) including the QKD network (hereinafter referred to as "QKDN") and the user network are installed at locations A, B, and C, respectively.

[0015] The quantum layer consists of QKD module 2 (an example of a QKD device) and QKD link 3. The main function of the quantum layer is to exchange photons and classical information (control information transmitted and received via a normal control link different from the QKD link) with QKD module 2 located at a separate site, and to share a link key (random number sequence). Furthermore, the quantum layer has the function of supplying random number sequences to KM10 (10a~10c). The link key (quantum cryptography key) shared via QKD link 3 is guaranteed not to be intercepted based on the principles of quantum mechanics. When encrypted data communication is performed using an encrypted communication method called a one-time pad with the shared link key, information theory guarantees that the transmitted and received data cannot be deciphered by any eavesdropper with any knowledge. QKD modules 2 (2a, 2b-1, 2b-2, and 2c) are each connected by QKD link 3 via optical fiber or the like.

[0016] However, the QKD technology's method of sharing link keys has limitations on the distance over which the link key can be shared, due to the use of single photons as the medium. For example, as shown in the quantum layer example in Figure 1, QKD module 2 is basically one-to-one, but in the case of relaying, at least two QKD modules 2b-1 and 2b-2 are required at relay site B. In the example in Figure 1, application key K is shared between site A and site C. A AC This shows the case where the following is supplied. At site B, the QKD module 2b-1 uses the same link key K as at site A, and the application key encrypted at site A. L AB (That is, it is decrypted using a shared key where the encryption key and decryption key are the same.) Then, the QKD module 2b-2 converts the decrypted application key to the link key K L BC Then encrypt it again, and the encrypted app key K A AC Relay it to base C.

[0017] To guarantee unconditional security, QKD inevitably sacrifices some communication performance, such as distance and speed. Generally, the link key generation rate is around 200,000 to 300,000 bits per second (200 to 300 kbps) within a 50km radius of laid fiber. By implementing and optimizing the QKD key distillation process in hardware, the QKD key generation speed can reach up to 10 Mbps over short distances.

[0018] To maintain a key generation speed of Mbps, it is necessary to install relay nodes at distances that allow for Mbps to be maintained and to perform key relay between relay points. On the other hand, the relay points will incur processing time for encryption and decryption.

[0019] The key management layer consists of key management devices (KM) 10a to 10c and KM links. The main functions of the key management layer include supplying application keys to applications 5a and 5c, which actually encrypt data, and relaying keys to other locations via KM links. Key management devices (KM) 10a to 10c are responsible for overall key management, including receiving key requests from applications 5a and 5c and storing interfaces.

[0020] The QKD network control layer consists of the QKD network controller 4 and links. The QKD network control layer controls the services of the entire QKD network. There may be a QKD network controller at each site, or as shown in Figure 1, there may be one (or more) for the entire quantum cryptography communication system. Alternatively, the QKD network controller 4 and KM10 may be implemented as a single unit.

[0021] The QKD network management layer includes a QKDN control unit 6. The QKD network management layer collects performance information from each layer, monitors whether services are operating properly, and commands the QKD network control layer to take control as needed. There may be multiple QKDN control units 6 depending on the configuration of the QKD network. The functions of the QKDN control unit 6 may also be implemented and executed by the KM10.

[0022] The service layer configuration varies depending on the user, but it consists of applications 5a and 5c for implementing encrypted communication, as well as computer modules. The service layer also has the function of encrypting the application key with the link key and transferring it to the neighboring node. Note that application 5 of the service layer may generate a separate encryption key (application key) from random number information, independently of QKD.

[0023] At the service layer, application keys are primarily used for encryption using symmetric encryption schemes. Symmetric encryption schemes are encryption methods that use the same application key, which has been shared in advance between the sender and receiver, to encrypt and decrypt communication data and messages. Specifically, application keys are used in encryption methods such as Advanced Encryption Standard (AES) and One Time Pad (OTP).

[0024] The user network management layer includes the user network control unit 7. The user network management layer collects performance information from the service layer and monitors whether the services are operating properly.

[0025] Note that the architecture shown in Figure 1 represents the basic elements. In reality, the configuration of the architecture may change depending on the situation. For example, the number of locations is not limited to 3. Also, for example, the number of applications 5 is not limited to 2. Also, for example, the number of QKDN control devices 6 in the QKD network management layer is not limited to 1.

[0026] The user network described above is a public network in which encrypted communication is performed by application 5. Application 5 runs on information processing devices 8, such as personal computers and smart devices. The user network is a data communication network, such as the Internet and cellular communication networks.

[0027] On the other hand, the aforementioned QKD network (quantum cryptography communication network) is a private network, and nodes (QKD nodes / nodes) are set up according to actual needs. The nodes provide encryption keys for encrypted communication to the user network.

[0028] The user network and the QKD network are loosely coupled. Therefore, application 5 does not have information about the configuration of the QKD network. Information about the QKD network configuration would be, for example, mapping information indicating which application 5 is connected to which KM10.

[0029] Figure 2 shows an example of a quantum cryptographic communication network 100 according to the embodiment. Note that Figure 2 is an example of a small-scale QKDN because the number of KM10s is small, at 8.

[0030] The key sharing network (KSN) 102 in the key management layer consists of KM10 and links between KM10s. The QKDN management layer is equipped with a QKDN control device 6 that communicates with the KM10s of the KSN 102.

[0031] At the quantum layer, a network 101 is configured, which includes multiple QKD modules 2 and multiple QKD links 3 between the QKD modules 2. Since the connections between the QKD modules 2 are one-to-one, the number of QKD modules 2 corresponding to the higher-level KM10 is installed according to the number of links connected to the higher-level KM10.

[0032] The QKDN controller 4 in the QKDN control layer controls the services in the key management layer and the quantum layer. Control of the quantum layer may also be performed via KM10.

[0033] Applications S and D in the user network communicate securely via the data communication network 103, using encryption and decryption application keys provided by the KM10 connected to each of them.

[0034] The QKD network is equipped with a QKDN control unit 6 that communicates with the KM10 of the KSN102. The QKDN control unit 6 manages the quantum layer via the KM10, similar to the QKDN controller 4. Furthermore, the QKDN control unit 6 directly manages the QKD link network 101.

[0035] Note that the number of KM10s, QKD modules 2, and applications 5 are not limited to the example in Figure 2.

[0036] The mapping information for KM10 and QKD module 2 can be managed and shared by each KM10 in a distributed manner, or managed by a dedicated mechanism (for example, by a single authoritative root server device) in a centralized manner. In this embodiment, the centralized manner in which the mapping information is managed by the QKDN control device 6 will be described.

[0037] Figure 3 shows an example of sharing application key information in the application 5, KM10, QKDN controller 4, and QKDN control device 6 of the embodiment. In the example in Figure 3, KM10 is indicated by an ID that identifies KM10. For example, the ID that identifies KMx011 is x011.

[0038] The KSN102 has two types of KM10s: one that provides the application key to the higher-level application 5, and another that does not connect to application 5 but relays the application key to share it with the destination KM10.

[0039] When KM10 connects to application 5 in the data communication network 103, it collects mapping information indicating the connection status. For example, the mapping information includes an ID that identifies application 5 and an ID that identifies KM10.

[0040] KM10 receives an application key request from application 5. For example, the application key request includes the following information: (1) The sender's application ID (2) Destination application ID (3) Amount of application key required (4) Expiration date of the app key (5) Types of services

[0041] The above is just an example, and other information may be included in the application key request. Also, if the sender's application ID is obvious (for example, if it is application 5 that sent the application key request), the sender's application ID does not need to be included in the application key request.

[0042] In the example shown in Figure 3, the KMx011 connects to multiple applications 5 (applications S1, S2, and S3). Application S1 communicates securely with application D1. Application S2 communicates securely with application D2. Application S3 communicates securely with application D3. The KMx011 collects application key information from each of the applications 5.

[0043] Furthermore, each KM10 in the KSN102 is connected to multiple applications 5 depending on the actual operating conditions. In the example in Figure 3, the dotted arrows input to each KM10 indicate the connection to application 5.

[0044] Each KM10 collects the mapping information and application key information described above and shares the mapping information and application key information with the QKDN control unit 6. For example, the mapping information and application key information may be transmitted to the QKDN control unit 6 via the QKDN controller 4. Alternatively, for example, the mapping information and application key information may be transmitted to the QKDN control unit 6 via the KSN102 by each KM10.

[0045] Furthermore, when KM10 connects to application 5, it shares mapping information with the QKDN control unit 6. Application key information is usually shared periodically with the QKDN control unit 6, but it may also be shared when KM10 receives an application key request from application 5.

[0046] [Example of KM's functional configuration] Figure 4 shows an example of the functional configuration of the KM10 in this embodiment. The KM10 in this embodiment includes a communication unit 11, a storage unit 12, and a processing unit 13.

[0047] The communication unit 11 is implemented by a communication interface that communicates using at least one of the following methods: wireless or wired. The communication unit 11 includes an application communication unit 111, a control communication unit 112, and a KM communication unit 113.

[0048] The application communication unit 111 communicates with the application 5 of the user network, which is the highest-level service layer, to share information such as application key requests.

[0049] The control communication unit 112 communicates with the QKDN control device 6 in the key management layer of the QKD network to share, for example, the mapping information, application key information, and key relay route information mentioned above.

[0050] The KM communication unit 113 communicates with one or more KM10s in the key management layer of the QKD network to share an encryption key (application key).

[0051] The communication unit 11 may be implemented without being divided into the three functional configurations described above.

[0052] The storage unit 12 is implemented using storage media such as an HDD (Hard Disk Drive), optical disc, memory card, and RAM (Random Access Memory).

[0053] The memory unit 12 stores connection information, key relay route information, application key information, link key information, application key distribution plan, and application keys shared between KM10.

[0054] Connection information includes, for example, the ID information of the KM10 connected to application 5, and a pair of ID information for the two applications 5 performing secure communication.

[0055] The key relay routing information is the routing information for performing key relay to share the application key with the specified KM10.

[0056] The application key information includes the amount of application keys requested, the expiration date of the application keys, the service type of application 5, and the amount of application keys pre-stored in KM10.

[0057] Link key information includes the amount of link keys stored in KM10, the number of connected QKD modules 2 and QKD links 3, the key generation speed of each link key, and the QEBR of each link key.

[0058] The application key allocation plan is obtained from the QKDN control unit 6. The application key allocation plan is a plan for sharing application keys between KM10s. Application key sharing is performed according to the application key allocation plan, at a specified time, in a specified amount, and using a specified application key relay path.

[0059] The processing unit 13 is implemented by at least one processing unit and performs the processing of KM. This processing unit includes, for example, a control unit and an arithmetic unit, and is implemented by analog or digital circuits. The processing unit may be a central processing unit (CPU), a general-purpose processor, a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a combination thereof. The processing unit described later may also be implemented by a processing unit similar to the processing unit 13.

[0060] The processing unit 13 includes an information exchange unit 131, a calculation unit 132, an execution unit 133, a key processing unit 134, a provision unit 135, a management unit 136, a control unit 137, and a platform unit 138.

[0061] The information exchange unit 131 obtains connection information with application 5, application key information, and application key distribution plan from the communication unit 11. The information exchange unit 131 also shares the connection information, key relay route information, and application key information stored in the storage unit 12 with the QKDN control device 6 via the control communication unit 112.

[0062] The calculation unit 132 periodically reads application key information from the storage unit 12 and calculates the required amount of application keys to be replenished. The calculation unit 132 also periodically reads link key information from the storage unit 12 and calculates the amount of link keys that can be used. The calculation unit 132 inputs the calculated information to the information exchange unit 131.

[0063] The execution unit 133 executes key relay between KM10 according to the above application key distribution plan and stores the shared application keys in the storage unit 12.

[0064] The key processing unit 134 inputs the application key to the provisioning unit 135 in accordance with the key request from application 5. Specifically, the key processing unit 134 determines the amount of application keys requested, the provision time for providing the application keys to application 5, and the destination indicating where the application keys will be provided, in response to the request from application 5.

[0065] When the provisioning unit 135 receives an application key from the key processing unit 134, it provides the application key to the application 5 on the user network of the service layer. For example, the provisioning unit 135 provides the requested amount of application keys determined by the key processing unit 134 to the recipient determined by the key processing unit 134, by the provision time determined by the key processing unit 134. Note that the functions of the provisioning unit 135 may be included in the communication unit 11.

[0066] The management unit 136 manages key resource information. For example, key resource information includes the number of QKD modules 2 connected to the KM10, the key generation speed and QBER (Quantum Bit Error Rate) of each QKD link 3, the amount of keys held between each QKD link 3, and the amount of pre-stored application keys for each destination KM10.

[0067] The control unit 137 controls the processing performed by the KM10. For example, the control unit 137 is responsible for controlling the activation and operation of each function of the KM10. Also, for example, the control unit 137 is responsible for synchronizing the cycles of each KM10 and the QKDN control device 6.

[0068] The platform unit 138 provides the computer operating system functions, basic network functions, and security functions necessary for managing and operating the functions on the KM10.

[0069] The configuration of the KM10 in this embodiment has been described above. However, the above configuration is just one example.

[0070] [Example of QKDN control unit function configuration] Figure 5 shows an example of the functional configuration of the QKDN control device 6 of the embodiment. The QKDN control device 6 of the embodiment includes a communication unit 61, a storage unit 62, and a processing unit 63. The hardware implementation method of the communication unit 61, storage unit 62, and processing unit 63 is the same as that of the communication unit 11, storage unit 12, and processing unit 13 of the KM10.

[0071] The QKDN control device 6 of this embodiment is connected to a plurality of KM10s that provide application keys used for encrypting or decrypting communications between applications 5 in the user network to applications 5. The QKDN control device 6 of this embodiment is also connected to the QKD module 2 which is connected to the KM10s.

[0072] The communication unit 61 comprises a KM communication unit 611 and a QKD module communication unit 612.

[0073] The KM communication unit 611 communicates with one or more KM10s. For example, the KM communication unit 611 communicates to share ID information that identifies the KM10, ID information that identifies the application 5 connected to the KM10, application key information obtained from the KM10, and key relay routing information within the KSN102. The application key information includes, for example, the amount of application keys that need to be shared to the specified destination KM10, and the service type of the application 5.

[0074] The QKD module communication unit 612 communicates with the QKD module 2 connected to the QKD link 3. For example, the QKD module communication unit 612 communicates to share link key information used for sharing application keys in the KSN102. Link key information includes, for example, the amount of link keys stored in each link and the link key generation speed.

[0075] The QKDN control device 6 may obtain the link key information via the KM10 connected to the QKD module 2 without communicating with the QKD module 2. Furthermore, the communication unit 61 may be implemented without being divided into the two configurations described above.

[0076] The memory unit 62 stores importance information, mapping information, link key information, application key information, key relay route information, and application key allocation plan.

[0077] The importance information includes the importance level, service type, the ID information of the originating application 5, and the ID information of the destination application 5. Details of the importance information will be described later using Figure 9.

[0078] The mapping information includes pairs of KM10 and application 5.

[0079] Link key information is obtained from QKD module 2 or KM10. This information includes details such as the number of link keys available for each link in KSN102.

[0080] Application key information is obtained from each KM10. This information includes the required number of application keys to be replenished, as well as the ID information and service type of the application pair performing secure communication. Details of the application key information will be described later using Figure 8.

[0081] The key relay routing information includes routing information for application key sharing between specified KM10 pairs.

[0082] The above-mentioned importance information, mapping information, link key information, application key information, and key relay route information are used to formulate the optimal application key allocation plan.

[0083] The processing unit 63 includes an information collection unit 631, a decision unit 632, a formulation unit 633, a management unit 634, a control unit 635, and a platform unit 636.

[0084] The information gathering unit 631 acquires the mapping information, link key information, application key information, and key relay route information from the communication unit 61 and stores them in the storage unit 62.

[0085] Based on the mapping information, the determination unit 632 identifies each KM10 pair that shares the application key used for communication of application 5. Then, according to the importance information described above, the determination unit 632 determines the importance of the communication of application 5 and assigns importance levels to each KM10 pair that shares the application key used for communication of application 5. The determination unit 632 also inputs the importance levels between each KM10 pair, based on the importance of the communication of application 5, to the formulation unit 633.

[0086] The planning unit 633 reads application key information, link key information, and key relay route information from the storage unit 62, formulates an application key allocation plan based on the importance level from the decision unit 632, and stores it in the storage unit 62. The planning unit 633 also transmits the application key allocation plan to the KM10 that share the application key via the KM communication unit 611.

[0087] The management unit 634 manages information about the KM10 connected to the QKDN control device 6, the number of KM10s, information about the QKD module 2, and the number of QKD modules 2.

[0088] The control unit 635 controls the processing performed by the QKDN control device 6. For example, the control unit 635 is responsible for controlling the activation and operation of each function.

[0089] The platform unit 636 provides the computer operating system functions, basic network functions, and security functions necessary for managing and operating the functions on the QKDN control unit 6.

[0090] [Example of the functional configuration of an information processing device] Figure 6 shows an example of the functional configuration of the information processing device 8 of the embodiment. The information processing device 8 of the embodiment includes a communication unit 81, a storage unit 82, and a processing unit 83. The hardware implementation method of the communication unit 81, storage unit 82, and processing unit 83 is the same as that of the communication unit 11, storage unit 12, and processing unit 13 of KM10.

[0091] The communication unit 81 receives an application key from the KM10, which is connected to the QKD module 2 that generates the link key, via QKD. This application key is used to encrypt or decrypt communication between applications 5 in the user network (an example of a source and destination). When this application key is relayed from the source KM10 belonging to KSN102 to the destination KM10, it is encrypted and transmitted using the link key, and then transmitted from the destination KM10 to the application 5.

[0092] The storage unit 82 stores, for example, an application key used for encryption for each destination of communication from the application 5 that sends the data. Also, for example, the storage unit 82 stores an application key used for decryption for each source of communication from the application 5.

[0093] The processing unit 83 encrypts communication with the destination application 5, for example, by operating the application 5 at the data source. Also, for example, the processing unit 83 decrypts the data received from the application 5 at the source by operating the application 5 at the data destination.

[0094] Note that the configurations of the KM10, the QKDN control device 6, and the information processing device 8 in this embodiment are examples, and the configurations may be changed as appropriate. For example, the functions of the QKDN control device 6 may be provided in at least one KM10 belonging to the KSN102. The configuration in which the functions of the QKDN control device 6 are provided in the KM10 will be described later as a modification of this embodiment.

[0095] FIG. 7 is a diagram showing an example of the application key distribution process by the QKDN control device 6 of the embodiment. In the example of FIG. 7, there are a plurality of pairs of applications 5 in the data communication network 103. The application S which is the source application 5 and the applications D1 to D which are the destination applications 5 γ exist.

[0096] When each KM10 in the KSN102 connects to the application 5, the KM10 notifies the QKDN control device 6 of the ID of the application 5 (for example, the IP address of the application 5) and the ID of its own device (for example, the IP address of the KM10). The QKDN control device 6 manages the above ID information notified from each KM10 as mapping information indicating the connection relationship between the application 5 and the KM10.

[0097] An application key is shared in advance between the KM10s connected to the application 5. The number of the application key databases K A Source,Destination depends on the number of pairs of the application 5 at the starting point and the application 5 at the destination that perform secure communication in the KM10. For example, in KMx001, the applications D1 to D that perform secure communication with the application S γA separate database of application keys will be set up for each application.

[0098] For example, if there are multiple pairs of application 5 between KMx001 and KMx543, generally, an application key database is installed for each pair of application 5. However, the application key database may also be installed for each KM10 without distinguishing the destination application 5.

[0099] When application S performs secure communication with application D1, application S sends the application key (KMx001) to KMx001. Are D1 ) is requested. When application S requests an application key, it notifies the destination application D1 of application key information, including the ID of the destination application D1, the expiration date of the application key, the type of service, and the amount of application key requested.

[0100] KMx001 is the database K of application D1. A S,D1 The system checks the amount of application keys requested and compares it with the amount of application keys already shared and stored. If the amount of application keys requested is met, KMx001 provides the application keys to application S.

[0101] If the requested amount of application keys is not met, KMx001 calculates the amount of application keys that need to be replenished. It sends application key information, including the amount of application keys that need to be replenished, the ID of the destination application D1, the expiration date of the application keys, and the service type, to the QKDN control unit 6. The QKDN control unit 6 stores the application key information received from KMx001 in, for example, an application key information table (see Figure 8).

[0102] KM10 Link Key Database K L No.The number depends on the number of QKD links 3 connected to KM10 at node 1 of each site. For example, if KMx001 is connected to Q QKD links 3, then there are Q link key databases. Each link key database stores link key information, including the amount of link keys stored, the link key generation rate, and the Quantum Bit Error Rate (QEBR) of the link key.

[0103] Furthermore, if multiple pairs of QKD modules 2 are installed between Node 1 at two locations and multiplexed onto a single QKD link 3, the number of link key databases may be the same as the number of QKD links 3, or the same as the number of pairs of QKD modules 2.

[0104] The QKDN control unit 6 also collects information on each QKD link 3 in the quantum layer. Normally, the QKDN control unit 6 collects information on QKD link 3 from the KM10 connected to the QKD module 2, but it may also collect information on QKD link 3 directly from the QKD module 2.

[0105] The QKDN control unit 6 periodically collects the mapping information, application key information, link key information, and key relay path from each KM10, and formulates an optimal application key distribution plan for each KM10 based on the collected information.

[0106] Specifically, the determination unit 632 assigns importance to the communication between pairs of applications 5 based on the ID of the destination application 5 and the service type, according to predetermined importance information. Then, the planning unit 633 calculates the amount of link keys that each link of KSN102 will be able to use for encryption and decryption in the next cycle, based on the amount of link keys stored and the link key generation rate. Finally, the planning unit 633 formulates an optimal application key allocation plan based on the required amount of application keys to replenish, the amount of link keys that can be provided, the importance of the communication between pairs of applications 5, and the key relay path.

[0107] In other words, the planning unit 633 determines the priority and proportion of app key sharing between each pair of applications 5. The formulated app key allocation plan is notified to each KM 10 via the QKDN controller 4.

[0108] The QKDN control unit 6 and the QKDN controller 4 may be implemented as an integrated unit.

[0109] Figure 8 shows an example of application key information in an embodiment. The example in Figure 8 shows the case where application key information is stored in the QKDN control device 6 in a table data format. The application key information table in Figure 8 includes pair index number, source application ID, destination application ID, source KM ID, destination KM ID, delivery deadline, service type, and replenishment requirement.

[0110] The pair index number is a number that is automatically assigned when adding a record (data) to the application key information table.

[0111] The source application ID is, for example, information about the interface of the device on which source application 5 is running. For example, the source application ID is an IP address (IPv4 or IPv6). The application key is provided from KM using this interface.

[0112] The destination application ID is, for example, information about the interface of the device on which destination application 5 is running. The explanation of the destination application ID is the same as that of the source application ID, so it will be omitted here.

[0113] The source and destination application IDs are obtained from application 5.

[0114] The source KM ID is, for example, information about the interface of the device on which KM10, to which source application 5 is connected, operates. For example, the source KM ID is the IP address of KM10.

[0115] The destination KM ID is, for example, information about the interface of the device on which the KM10, to which the destination application 5 is connected, is running. For example, the destination KM ID is the IP address of the KM10.

[0116] The starting KM ID is shared with the QKDN control unit 6 from KM10 along with the application ID, while the destination KM ID is identified based on the mapping information shared with the QKDN control unit 6.

[0117] The deadline is the deadline for providing the application key. If the KM communication unit 611 is unable to provide the application key by this deadline, it will send feedback to application 5 indicating that it is unable to provide the application key.

[0118] The service type is the type of service that enables secure communication between pairs of applications. For example, service types include predefined information such as finance, healthcare, personal information, defense, and government.

[0119] The amount of application keys required and the deadline for providing them vary depending on the type of service. For example, in the financial sector, the amount of application keys required is less than in other service types, but the deadline for providing them is stricter. Also, in the medical sector, the amount of application keys required is more than in other service types, but the deadline for providing them is less strict.

[0120] The application key request amount indicates the amount of application keys used when secure communication is performed between pairs of applications (5).

[0121] Note that the amount of application key required varies depending on the encryption method. For example, with AES encryption, the application key is reused within a certain period, so the amount of application key required is less than with OTP. With OTP encryption, the same amount of application key is required as the amount of communication data, so the amount of application key required is greater than with AES.

[0122] The information gathering unit 631 periodically updates the application key information table. For example, after an application key allocation plan has been formulated, if an application key request is fulfilled, the information gathering unit 631 deletes the record corresponding to that application key request from the application key information table. Also, for example, if an application key request is partially fulfilled, the information gathering unit 631 calculates the amount of application keys that are missing and updates the application key information table. Also, for example, when a new record is added to the application key information table, if it is an application key request between pairs of the same application 5, the information gathering unit 631 merges the new record with the old record.

[0123] Note that the application ID may change due to changes in, for example, the IP address assigned by the DHCP (Dynamic Host Configuration Protocol) server. Specifically, the application ID may change when the computer on which application 5 is running is restarted. In this case, for example, application 5 notifies the KM10 connected to application 5 of the changed application ID. The KM10 then sends a notification of the change in the mapping information table, including the changed application ID, to the QKDN control device 6.

[0124] Furthermore, when application 5 stops a service, it notifies KM10, which is connected to application 5, of the service stoppage. KM10 then sends a service stoppage notification to QKDN control unit 6, requesting a change or deletion of the mapping information table.

[0125] Furthermore, if QDKN becomes large-scale and the number of KM10s increases, KSN102 may be divided into multiple KSN domains to make its management more efficient and easier. When KSN102 is divided into multiple KSN domains, ID information identifying the domains is added to the mapping information table.

[0126] Figure 9 shows an example of importance information in an embodiment. The example in Figure 9 shows the case where importance information is stored in the QKDN control device 6 in a table data format. The importance information table in Figure 9 includes importance, service type, source application ID, and destination application ID.

[0127] The importance level is the level of importance of the service type. The importance level is referenced as one of the criteria when formulating an application key allocation plan. For example, the importance level is expressed by a number from 9 to 1, with a higher value indicating higher importance. The determination unit 632 identifies the pair of applications 5 (source and destination applications 5) for which the application key is requested from the application key request, and assigns a weight level to the application key request according to the pair of applications 5.

[0128] The service type is defined for each application before application 5 obtains the application key from QKDN. In the example in Figure 9, there are three types: security (importance 9-7) such as defense, diplomacy, and government; security (importance 6-4) such as finance and biometrics; and security (importance 3-1) such as healthcare and personal information.

[0129] The explanation of the source application ID and destination application ID is the same as in Figure 8, so it will be omitted here.

[0130] The importance level is assigned based on at least one of the following: service type, source application ID, and destination application ID. Furthermore, the importance level may be assigned by an external device other than the QKDN device 6, or it may be determined by a standard or other agreement.

[0131] As a method for assigning importance based on service type, for example, diplomatic services in the security sector are assigned a high importance level (7-9) because they have a higher real-time capability than other service types. Similarly, banking services in the financial sector are assigned a medium importance level (4-6) because they have a lower key requirement and a higher real-time capability than other service types. Furthermore, genome information sharing services in the medical sector are assigned a low importance level (1-3) because they have a higher key requirement but a lower real-time capability than other service types.

[0132] One method for assigning importance based on source and destination application IDs is to assign importance according to the importance of the communication from source application 5 to destination application 5.

[0133] As a method of assigning overall importance by combining service type, source application ID, and destination application ID, for example, an application key request from a dedicated IP address at Ministry of Foreign Affairs base A to a dedicated IP address at Ministry of Foreign Affairs base B, used for diplomatic services, would be assigned importance level 8. Alternatively, for example, an application key request from ○○○ Bank ○○○ Branch to ○○○ Bank ○○○ Branch in financial services would be assigned importance level 6.

[0134] The above importance information is defined in advance before the application key is provided from QKDN to application 5. In the example in Figure 9, the importance is defined by a number from 1 to 9, but it may be defined more finely or more coarsely depending on the actual operating situation. Also, the importance is usually assigned by the QKDN control unit 6, but it may also be assigned by KM10.

[0135] Figure 10 is a flowchart showing an example of the application key distribution process in the embodiment. First, when each KM10 connects to application 5, the KM communication unit 611 collects mapping information (for example, the IDs of the source application 5 and KM10 respectively) from each KM10 (step S1).

[0136] Next, when the KM communication unit 611 receives an application key request containing application key information from each KM10, it collects the application key information from each KM10 (step S2). For example, the application key information includes the amount of application key requested, the ID of the destination application 5, the expiration date for providing the application key, and the service type of application 5.

[0137] Next, the KM communication unit 611 collects the required amount of application keys from each KM10 (step S3). The required amount of application keys is calculated by each KM10. Specifically, each KM10 compares the required amount of application keys between pairs of applications 5 with the amount of application keys between pairs of applications 5 that have been previously stored in each KM10, and calculates the required amount of application keys for each KM10.

[0138] Furthermore, the application key information collected in step S2 may not include the requested amount of application keys, and only the required amount of application keys to be replenished in step S3 may be sent to the QKDN control device 6.

[0139] Next, the determination unit 632 assigns importance to each replenishment requirement collected in step S3 (step S4). Specifically, the determination unit 632 assigns importance to the replenishment requirement of application keys between the application 5 pair and the KM10 connected to it, based on the service type, the ID of the source application 5, and the ID of the destination application 5.

[0140] Next, the KM communication unit 611 and the QKD module communication unit 612 collect link key information from each KM10·QKD module 2 (step S5). For example, the link key information includes the amount of link keys stored, the number of QKD links, the link key generation speed, and the QEBR of the link keys.

[0141] Next, the planning unit 633 calculates the amount of link keys available for each link in the application key relay based on the link key information collected in step S5 (step S6).

[0142] Next, the KM communication unit 611 collects key relay route information from the QKDN controller 6 and each KM10 (step S7).

[0143] Next, the planning unit 633 formulates an optimal application key allocation plan based on (1) the required amount of application keys to be replenished from each KM10, (2) the importance of each application key request, (3) the amount of link keys available for each link, and (4) the key relay path for sharing application keys (step S8).

[0144] Next, the KM communication unit 611 notifies each KM10 of the application key distribution plan formulated in step S8 via the QKDN controller 4 (step S9).

[0145] Each KM10 shares the application key according to the application key distribution plan. Once each KM10 has finished sharing the application key, it provides the application key to application 5 and waits for the next application key to be shared.

[0146] Figure 11 is a diagram illustrating an example of how to formulate an application key allocation plan in an embodiment. For example, KSN102 is configured in the topology shown in Figure 11. In the example in Figure 11, the following information is collected by the QKDN control device 6.

[0147] The KSN102 has 16 KM10A to 10P. In Figure 11, the 16 KM10A to 10P are represented by the symbols A to P. Of the 16 KM10A to 10P, KM10A, 10B, 10C, 10D, 10M, 10N, 10O, and 10P are connected to application 5. The remaining KM10s exist as relay KMs for application key sharing.

[0148] KM10A and KM10M are pairs of KM10s that provide the same application key to a higher level. Sharing of the application key is required between KM10A and KM10M. KM10B and 10N, KM10C and 10O, and KM10D and 10P are each pairs of KM10s. Sharing of the application key is required between each of KM10B and 10N, KM10C and 10O, and KM10D and 10P, just as it is between KM10A and KM10M.

[0149] The underlined numbers above each KM10A-10P represent the amount of application keys that need to be shared between each KM10 pair in the next cycle (the amount of application keys that need to be replenished). For example, 70 application keys (units are arbitrary, e.g., keys, Kbit, or KB) need to be shared between KM10A and KM10M. Similarly, the application key replenishment amounts required for KM10B and 10N, KM10C and 10O, and KM10D and 10P are 60, 300, and 80, respectively.

[0150] Additionally, the number enclosed in a square next to each KM10 indicates its importance. For example, the importance of app sharing between KM10A and KM10M is 9. Similarly, the importance of KM10B and 10N, KM10C and 10O, and KM10D and 10P are 6, 2, and 6, respectively.

[0151] Furthermore, the lines between KM10s indicate a relay path that relays the application key to the destination KM10. In the relay path, the link key generated by the lower QKD link 3 and provided to the KM10 is consumed.

[0152] If there is no line between KM10s, it means that there is no lower QKD link 3 between those KM10s. The number assigned to the links included in the relay path indicates the amount of available link keys. The amount of available link keys is the total amount of link keys that can be provided from the lower QKD link 3 between KM10s. The amount of available link keys is the sum of the accumulated amount of lower link keys and the link keys generated within one cycle.

[0153] For example, if the link key sharing process has a cycle of 60 seconds, between KM10A and 10E, in addition to the 174 link keys already stored, link keys are generated at a generation rate of 6. Therefore, between KM10A and 10E, 360 new link keys are generated by the next cycle. In other words, between KM10A and 10E, the amount of link keys available for use by the start of the next cycle is 534 (174 + 360).

[0154] Furthermore, the QKDN control unit 6 also collects the application key relay paths between the four KM10 pairs from the KSN102 QKDN controller 4 and each KM10. The application key relay path between KM10A and 10M is AEHIJM. The application key relay path between KM10B and 10N is BEHIJN. The application key relay path between KM10C and 10O is CFHIKO. The application key relay path between KM10D and 10P is DGLP.

[0155] Note that the relay path for application keys may change in each cycle due to changes in the amount of available link keys.

[0156] [Method 1: A method that emphasizes balance] Figure 12 shows a specific example 1 of the method for formulating an application key allocation plan according to the embodiment. In method 1 shown in Figure 12, the proportion of the available link keys is calculated according to importance, and an optimal application key allocation plan is formulated based on the proportion of available link keys. Specifically, the formulation unit 633 determines that the proportion of the stored link key amount to be used is higher for higher importance, and formulates an allocation plan based on that proportion.

[0157] The example in Figure 12 describes the case where the link key sharing process has a cycle of 60 seconds. The explanation of the symbols in Figure 12 is the same as in Figure 11, so it will be omitted. In Figure 12, the 16 KM10A~10P are represented by the symbols A~P. The amount of link keys available between each KM10 is represented by the number assigned to the link between each KM10.

[0158] In the example in Figure 12, there are four KM10 pairs that share application keys within one cycle. First, the determination unit 632 assigns importance to each KM10 included in each application key relay path between the four KM10 pairs. Specifically, the key relay path between KM10A and 10M is AEHIJM, and each KM10 is assigned an importance of 9. The key relay path between KM10B and 10N is BEHIJN, and each KM10 is assigned an importance of 6. The key relay path between KM10C and 10O is CFHIKO, and each KM10 is assigned an importance of 2. The key relay path between KM10D and 10P is DGLP, and each KM10 is assigned an importance of 6.

[0159] The determination unit 632 calculates the amount of link keys available for application key relays based on the cumulative importance ratio when the links between KM10 are used for multiple key relay paths. For example, the links between KM10H and 10I are used for three application key relay paths, so the cumulative importance is (9 + 6 + 2). The amount of available link keys between KM10H and 10I is 470. Therefore, within one cycle, 470 × 9 / 17 link keys (248) are available for the application key relay between KM10A and 10M. 470 × 6 / 17 link keys (165) are available for the application key relay between KM10B and 10N. 470 × 2 / 17 link keys (55) are available for the application key relay between KM10C and 10O.

[0160] The remaining link key (2) is used in the next cycle. Note that the actual amount of link key used is limited to the bottleneck of each link from the starting KM10 to the destination KM10.

[0161] For example, regarding application key sharing between KM10A and 10M, the amount of application keys available for each KM10 link in the application key relay path AEHIJM is as follows: Between AE, 534 link keys are available. Between EH, used for two application key relay paths, 9 / 15 link keys (430 × 9 / 15 = 258) are available. Between HI, used for three application key relay paths, 9 / 17 link keys (470 × 9 / 17 = 248) are available. Between IJ, used for two application key relay paths, 9 / 15 link keys (430 × 9 / 15 = 258) are available. Between JM, 400 link keys are available.

[0162] In other words, the amount of link keys available for each link between KM10A and 10M is A-(534)-E-(258)-H-(248)-I-(258)-J-(400)-M, with the bottleneck being 248 between H and I. To satisfy the required amount of 70 application keys to be shared between KM10A and 10M, 70 link keys are used in each link of the application key relay path AEHIJM. The remaining unused link keys are accumulated and carried over to the next cycle. That is, the remaining amount of link keys for each link is A-(464)-E-(188)-H-(178)-I-(188)-J-(330)-M.

[0163] Following the same calculation method, the amount of link keys available for each link between KM10B and 10N is B-(430)-E-(172)-H-(165)-I-(172)-J-(430)-N, with the bottleneck being 165 between HI. To satisfy the amount of 60 required for sharing application keys between KM10B and 10N, 60 link keys are used on each link of the application key relay path BEHIJN. The remaining unused link keys are accumulated and carried over to the next cycle. That is, the remaining link keys for each link are B-(370)-E-(112)-H-(105)-I-(112)-J-(370)-N. Note that since link EHIJ was shared, the remaining link keys become E-(112+188)-H-(105+178)-I-(112+188)-J.

[0164] Furthermore, the amount of link keys available for each link between KM10C and 10O is C-(420)-F-(261)-H-(55)-I-(270)-K-(360)-O, with the bottleneck being 55 between H and I. Since only 55 can be provided for the required amount of application keys to be shared between KM10C and 10O (300), 55 link keys are used for each link in the application key relay path CFHIKO. The remaining unused link keys are accumulated and carried over to the next cycle. In other words, the remaining link keys for each link are C-(365)-F-(206)-H-(0)-I-(215)-K-(305)-O. Also, within this cycle, 55 application keys are shared between KM10C and 10O, and the amount of application keys that will need to be shared in subsequent cycles is 245. Note that since link HI is shared with other application key relay paths, the remaining link key is H - (0 + 105 + 178) - I. Adding the previously mentioned unused link key amount of 2, the remaining link key between HIs becomes (2 + 0 + 105 + 178).

[0165] The amount of link keys available for each link between KM10D and 10P is D-(332)-G-(130)-L-(320)-P, with the bottleneck being 130 between GL. To satisfy the required amount of 80 application keys to share between KM10D and 10P, 80 link keys are used for each link in the application key relay path DGLP. The remaining unused link keys are accumulated and carried over to the next cycle. In other words, the remaining link keys for each link are D-(252)-G-(50)-L-(240)-P.

[0166] In summary, in Method 1, the amount of link keys available for each link between KM10 is as follows: A-(534)-E-(430×9 / 15)-H-(470×9 / 17)-I-(430×9 / 15)-J-(400)-M B-(430)-E-(430×6 / 15)-H-(470×6 / 17)-I-(430×6 / 15)-J-(430)-N C-(420)-F-(261)-H-(470×2 / 17)-I-(270)-K-(360)-O D-(332)-G-(130)-L-(320)-P

[0167] Furthermore, the advantage of the aforementioned method for formulating an application key allocation plan that emphasizes balance (Method 1) is that link keys can be evenly allocated based on importance. Method 1 is suitable for periodic and fixed use cases. A disadvantage is that sharing application keys between high-importance KM10s (for example, between KM10s whose importance is higher than a predetermined importance level) is inefficient because link keys can only be used in proportion to the amount allocated. For example, if the required replenishment amount of application keys between KM10A and 10M is 300 instead of 70, the bottleneck value of the key relay path calculated using Method 1 is 248, so the remaining 52 application keys must be carried over to the next cycle. If the amount of link keys available in the next cycle is less than 52, the sharing process will need to be performed again in the following cycle.

[0168] For example, if there are two relay paths X and Y as shown below, the sharing of the application key may be completed via relay path Y before that of relay path X. Relay path X:Y is more important, and requires more application keys than Y. Relay path Y: Lower importance than X, and requires less application key replenishment than X.

[0169] [Method 2: Prioritizing the Prioritization] Figure 13 shows a specific example 2 of the method for formulating an application key allocation plan according to the embodiment. Method 2 shown in Figure 13 is a method for formulating an allocation plan that prioritizes application key sharing according to importance. Specifically, the formulation unit 633 determines the order in which the accumulated link key amounts will be used, in descending order of importance, and formulates an allocation plan based on that order.

[0170] Figure 13 illustrates the case where the link key sharing process has a cycle of 60 seconds. The explanation of the symbols in Figure 13 is the same as in Figure 11 and will be omitted. In Figure 13, the 16 KM10A~10P are represented by the symbols A~P. The amount of link keys available between each KM10 is represented by the number assigned to the link between each KM10.

[0171] In Method 2, the amount of available link keys for links with matching importance and overlapping key relay paths is calculated based on the proportion of available keys.

[0172] First, between KM10A and 10M, which have an importance level of 9, the application key will be shared starting at time "t + (0 × i)". t is the start time of this period, and i is the specified interval.

[0173] The relay path for application keys between KM10A and 10M is AEHIJM. The amount of link keys available on each link is A-(534)-E-(430)-H-(470)-I-(430)-J-(400)-M, with the bottleneck being 400 between I and J. To satisfy the required amount of 70 application keys to be shared between KM10A and 10M, 70 link keys are used on each link of the application key relay path AEHIJM. The remaining unused link keys are used between KM10 in the following order of priority. That is, the remaining link keys on each link are A-(464)-E-(360)-H-(400)-I-(360)-J-(330)-M.

[0174] Next, KM10B and 10N, and KM10D and 10P, which have an importance level of 6, will share the application key starting from time "t + (1 × i)".

[0175] The relay path for application keys between KM10B and 10N is BEHIJN, and the relay path for application keys between KM10D and 10P is DGLP. Since the same link is not being used, the proportion of available application keys is not calculated.

[0176] For example, if the relay path for application keys between KM10D and 10P is DGFHIKLP, link HI will be shared. In this case, the proportion of available application keys will be calculated, and the remaining link keys between HI will be allocated 50%:50% respectively.

[0177] The amount of link keys available on each link between KM10B and 10N is B-(430)-E-(360)-H-(400)-I-(360)-J-(430)-N, with bottlenecks of 360 between EH and IJ. To satisfy the amount of application keys that need to be shared between KM10B and 10N (60), 60 link keys are used on each link of the application key relay path BEHIJN. The remaining unused link keys are used between KM10 in the following order of priority. That is, the remaining link keys on each link are B-(370)-E-(300)-H-(340)-I-(300)-J-(370)-N.

[0178] Furthermore, the amount of link keys available on each link between KM10D and 10P is D-(332)-G-(130)-L-(320)-P, with the bottleneck being 130 between GL. To satisfy the required amount of 80 application keys to be shared between KM10D and 10P, 80 link keys are used on each link of the application key relay path DGLP. The remaining unused link keys are used between KM10 in the following order of priority. That is, the remaining amount of link keys on each link is D-(252)-G-(50)-L-(240)-P.

[0179] Finally, between KM10C and 10O, which have an importance level of 2, the application key will be shared starting at time "t + (2 × i)".

[0180] The relay path for application keys between KM10C and 10O is CFHIKO, and the amount of link keys available on each link is C-(420)-F-(261)-H-(340)-I-(270)-K-(360)-O, with the bottleneck being 261 between F and H. Since 261 are available for the amount of application keys that need to be shared between KM10C and 10O (300), 261 link keys are used on each link of the application key relay path CFHIKO. The remaining unused link keys are accumulated and carried over to the next cycle. In other words, the remaining amount of link keys on each link is C-(159)-F-(0)-H-(79)-I-(9)-K-(99)-O. Also, within this cycle, 261 application keys are shared between KM10C and 10O, and the amount of application keys that need to be shared in the next cycle is 39.

[0181] In summary, in Method 2, the amount of link keys available for each link between KM10 is as follows: Order 1: A-(534)-E-(430)-H-(470)-I-(430)-J-(400)-M Order 2: B-(430)-E-(360)-H-(400)-I-(360)-J-(430)-N Order 2: D-(332)-G-(130)-L-(320)-P Order 3: C-(420)-F-(261)-H-(340)-I-(270)-K-(360)-O

[0182] Furthermore, if there are multiple transfers of application keys used for communication between applications 5 of equal importance, and the same link is used, the application keys are usually shared in order of their expiration dates. That is, when the planning unit 633 performs encrypted relay transfers of application keys used for communication between multiple applications 5 of equal importance, it formulates an allocation plan to perform encrypted relay transfers of application keys in order of the closest expiration dates. It is also possible to share application keys in a proportion that takes expiration dates into consideration, rather than in order of expiration dates.

[0183] The advantage of the priority-based application key allocation plan (Method 2) is that it allows for efficient sharing of application keys by prioritizing link keys based on their importance. The disadvantage is that application key sharing between high-importance KM10s (for example, between KM10s whose importance is higher than a predetermined importance level) is always prioritized, and the processing time for application key sharing between low-importance KM10s (for example, between KM10s whose importance is lower than a predetermined importance level) becomes longer, resulting in an unbalanced system. In an extreme example, if the amount of application keys needed to replenish between high-importance KM10s is greater than the amount of available link keys, application key sharing will only occur between high-importance KM10s.

[0184] [Method 3: A method that considers priority and balance] Figure 14 shows a specific example 3 of the method for formulating an application key allocation plan in the embodiment. Method 3 shown in Figure 14 is a method for formulating an allocation plan that combines priority and balance. Specifically, the formulation unit 633 determines the order in which to use the stored link key amount when the importance is above a predetermined importance, in descending order of importance, and determines the proportion of the stored link key amount to use when the importance is below the predetermined importance, with the proportion increasing as the importance increases. The formulation unit 633 then formulates an allocation plan such that encrypted relay transfer of application keys used for communication of applications with an importance below the predetermined importance is performed after encrypted relay transfer of application keys used for communication of applications with an importance of or greater than the predetermined importance.

[0185] The example in Figure 14 describes the case where the link key sharing process has a cycle of 60 seconds. The explanation of the symbols in Figure 14 is the same as in Figure 11, so it will be omitted. In Figure 14, the 16 KM10A~10P are represented by the symbols A~P. The amount of link keys available between each KM10 is represented by the number assigned to the link between each KM10.

[0186] In Figure 14, a priority threshold is defined as a predetermined level of importance. If the importance matches or is greater than the priority threshold, a priority is determined, an application key allocation plan is formulated, and the application key is shared preferentially. If the importance is less than the priority threshold, the proportion of application key usage is calculated, and an allocation plan is formulated according to that proportion. In other words, the sharing of application keys with higher priority is prioritized, followed by the sharing of application keys with lower priority, according to the proportion.

[0187] First, share the application key among KM10s that meet or exceed the importance threshold. For example, let's assume the importance threshold is 7.

[0188] KM10A and 10M, which have an importance of 9, are given first priority, and application key sharing will begin from time "t + (0 × i)". The relay path for application keys between KM10A and 10M is AEHIJM, and the amount of link keys available on each link is A-(534)-E-(430)-H-(470)-I-(430)-J-(400)-M, with the bottleneck being 400 between I and J. To satisfy the required amount of 70 application keys to be shared between KM10A and 10M, 70 link keys are used on each link of the application key relay path AEHIJM. The remaining unused link keys are used between the next priority KM10s. That is, the remaining amount of link keys on each link is A-(464)-E-(360)-H-(400)-I-(360)-J-(330)-M.

[0189] Although not shown in the example in Figure 14, for example, if there is a KM10 pair with an importance level of 8, the application key will be shared starting from time "t + (1 × i)". Also, if there are multiple transfers of application keys used for communication of applications 5 with equal importance levels, and the same link is used, the application keys are usually shared in order of their expiration dates, but they may also be shared in a proportion that takes the expiration dates into account.

[0190] Next, application keys are shared between KM10B and 10N, KM10D and 10P, and KM10C and 10O, which are second-ranked with importance criteria values ​​less than 7. The key relay route between KM10B and 10N is BEHIJN, and each KM10 is assigned an importance of 6. The key relay route between KM10C and 10O is CFHIKO, and each KM10 is assigned an importance of 2. The key relay route between KM10D and 10P is DGLP, and each KM10 is assigned an importance of 6.

[0191] For each KM10 included in the relay path, the accumulated importance is shown in the numbers enclosed in squares in Figure 14. The link between KM10H and 10I is shared by two relay paths, and the available link keys for each are 6 / 8 and 2 / 8 of the remaining 400. The amount of unused link keys is 0.

[0192] Specifically, the amount of link keys available on each link between KM10B and 10N is B-(430)-E-(360)-H-(300)-I-(360)-J-(430)-N, with the bottleneck being 300 between HI. To satisfy the required amount of 60 application keys to be shared between KM10B and 10N, 60 link keys are used on each link of the application key relay path BEHIJN. The remaining unused link keys are accumulated and carried over to the next cycle. In other words, the remaining link keys for each link are B-(370)-E-(300)-H-(240)-I-(300)-J-(370)-N.

[0193] The amount of link keys available on each link between KM10C and 10O is C-(420)-F-(261)-H-(100)-I-(270)-K-(360)-O, with the bottleneck being 100 between HI. Since only 100 can be provided for the 300 application keys that need to be shared between KM10C and 10O, 100 link keys are used on each link in the application key relay path CFHIKO. Unused link keys are accumulated and carried over to the next cycle. Therefore, the remaining link keys on each link are C-(320)-F-(161)-H-(0)-I-(170)-K-(260)-O. Also, within this cycle, 100 application keys are shared between KM10C and 10O, and the amount of application keys that will need to be shared in subsequent cycles is 200. Since link HI is shared, the remaining link key is H-(0+240)-I.

[0194] The amount of link keys available on each link between KM10D and 10P is D-(332)-G-(130)-L-(320)-P, with the bottleneck being 130 between GL. To satisfy the amount of application keys that need to be shared between KM10D and 10P (80), 80 link keys are used on each link of the application key relay path DGLP. The remaining unused link keys are accumulated and carried over to the next cycle. In other words, the remaining link keys for each link are D-(252)-G-(50)-L-(240)-P.

[0195] In summary, in Method 3, the amount of link keys available for each link between KM10 is as follows: Order 1: A-(534)-E-(430)-H-(470)-I-(430)-J-(400)-M Order 2: B-(430)-E-(360)-H-(400×6 / 8)-I-(360)-J-(430)-N Order 2: C-(420)-F-(261)-H-(400×2 / 8)-I-(270)-K-(360)-O Order 2: D-(332)-G-(130)-L-(320)-P

[0196] Furthermore, the method for formulating an allocation plan that balances priority and balance (Method 3) allows for more efficient sharing of application keys based on importance criteria. Specifically, the sharing of application keys with higher importance is prioritized, while application keys with lower importance are shared by using link keys equally.

[0197] The importance threshold can be a fixed value, or it can be varied according to the actual operational situation. For example, if the total amount of link keys stored in QKDN is insufficient (for example, if the amount stored is less than a predetermined amount), the importance threshold can be set higher than the predetermined value. Also, for example, if the number N of KM10s with an importance higher than a predetermined importance is significantly less than the number n of KM10s with an importance below a predetermined importance (for example, if the difference nN is greater than a predetermined difference value), the importance threshold can be set lower than the predetermined value.

[0198] As described above, in the QKDN control device 6 of the embodiment, the processing unit 63 formulates an allocation plan to distribute the application keys, which are encrypted and relayed between opposing KM10s using a link key shared by the QKD between opposing QKD modules 2 included in the QKDN, to the KM10s connected to each of the multiple applications 5, which use the application keys to encrypt or decrypt communications, based on the amount of application key requests from the multiple applications 5.

[0199] Furthermore, in the information processing device 8 of this embodiment, the communication unit 81 sends an application key request to the KM10, which includes destination identification information that identifies the destination of the data and the requested amount of application keys used to encrypt or decrypt the data, and receives the requested amount of application keys from the KM10. Then, the processing unit 83 operates an application 5 that encrypts or decrypts the data using the application keys. The application keys are encrypted and relayed between opposing KM10s by a link key shared by the QKD between opposing QKD modules 2 included in the QKDN, and are distributed to the KM10 connected to each of the multiple applications 5 by a wired or wireless communication method according to an allocation plan created based on the amount of application keys requested from the multiple applications 5.

[0200] According to the quantum cryptography communication system of this embodiment, application keys shared using QKD can be optimally distributed to multiple key management devices (multiple KM10 in this embodiment).

[0201] For example, in a large-scale QKD network where the number of KM10s exceeds 1,000, key sharing between KM10s becomes widespread, frequent, and complex. Furthermore, while QKDNs are built in response to key requests from applications 5, the key provisioning capacity of QKDNs is typically not designed to significantly exceed the requests from applications 5. In addition to regular, fixed-quantity application key requests, there may be urgent requests for application keys. According to the QKDN control device 6 of this embodiment, it is possible to prioritize the provision of application keys even in response to such urgent application key requests.

[0202] (Modified examples of the embodiment) Next, a modified example of the embodiment will be described. In the description of the modified example, explanations similar to those of the embodiment will be omitted, and the differences from the embodiment will be described. In the modified example, the case in which the functions of the QKDN control device 6 of the embodiment are provided in at least one KM10 belonging to the KSN102 will be described.

[0203] [Example of functional configuration] Figure 15 shows an example of the functional configuration of KM10-2, a modified version of the embodiment. The modified KM10-2 includes a communication unit 11-2, a storage unit 12-2, and a processing unit 13-2.

[0204] The communication unit 11-2 comprises an application communication unit 111 and a KM communication unit 113-2. The KM communication unit 113-2 further performs communication for creating, for example, application key information (Figure 8) of the embodiment.

[0205] The memory unit 12-2 further stores application key information (Figure 8) and importance information (Figure 9) of the embodiment.

[0206] In the processing unit 13-2, the information exchange unit 131-2 further creates the application key information (Figure 8) and other information based on the information received from each of the multiple KM10s. For example, the information exchange unit 131-2 creates application key information (Figure 8) based on the connection information received from each of the multiple KM10s. The information exchange unit 131-2 also shares the application key information (Figure 8) and other information with other KM10s via the KM communication unit 113-2.

[0207] Furthermore, the processing unit 13-2 includes a determination unit 139 and a planning unit 140. The determination unit 139 and the planning unit 140 correspond to the determination unit 632 and the planning unit 633 of the QKDN control device in the above-described embodiment. That is, the determination unit 139 assigns importance to the communication of application 5 based on importance information (Figure 9). The planning unit 140 formulates an application key allocation plan used for the communication of application 5 based on the importance. The application key allocation plan is shared with other KM10s via the KM communication unit 113-2.

[0208] According to a modified example, even if the QKDN control device 6 of the embodiment is not provided in the quantum cryptography communication network 100, it is possible to achieve the same functions as the quantum cryptography communication system of the embodiment.

[0209] Finally, an example of the hardware configuration of the QKD module 2, QKDN control device 6, information processing device 8, and key management device (KM) 10 of the embodiment will be described.

[0210] [Example hardware configuration] Figure 16 shows an example of the hardware configuration of the QKD module 2 of the embodiment. The QKD module 2 of the embodiment includes a control device 301, a main memory 302, an auxiliary memory 303, a display device 304, an input device 305, a quantum communication IF 306, and a classical communication IF 307.

[0211] The control device 301, main memory 302, auxiliary memory 303, display device 304, input device 305, quantum communication IF 306, and classical communication IF 307 are connected via bus 310.

[0212] The control device 301 executes the program read from the auxiliary storage device 303 into the main storage device 302. The main storage device 302 is memory such as ROM and RAM. The auxiliary storage device 303 is such as an HDD and memory card.

[0213] The display device 304 displays the status of the QKD module 2, etc. The input device 305 accepts input from the user. The display device 304 and the input device 305 may be implemented as touch panels or the like that have display and input functions. Furthermore, the display device 304 and the input device 305 do not have to be provided on the QKD module 2. In this case, for example, the display and input functions of an external terminal connected to the QKD module 2 may be used.

[0214] The quantum communication interface IF306 is an interface for connecting to the QKD link through which photons are transmitted. The classical communication interface IF307 is an interface for connecting to the transmission path through which control signals are transmitted between the opposing QKD module 2, and to the transmission path for communication with the key management device 10, etc.

[0215] Figure 17 shows an example of the hardware configuration of the QKDN control device 6, information processing device 8, and KM10 according to the embodiment. The QKDN control device 6, information processing device 8, and KM10 include a control device 401, a main memory 402, an auxiliary memory 403, a display device 404, an input device 405, and a communication IF 406.

[0216] The control device 401, main memory 402, auxiliary memory 403, display device 404, input device 405, and communication IF 406 are connected via bus 410.

[0217] The control device 401 executes the program read from the auxiliary storage device 403 into the main storage device 402. The main storage device 402 is memory such as ROM and RAM. The auxiliary storage device 403 is such as an HDD and memory card.

[0218] The display device 404 displays the status of the QKDN control device 6, the information processing device 8, and the KM10. The input device 405 accepts input from the user. The display device 404 and the input device 405 may be implemented as touch panels or the like that have display and input functions. Furthermore, the display device 404 and the input device 405 do not necessarily have to be provided in the QKDN control device 6, the information processing device 8, and the KM10. In this case, for example, the display and input functions of an external terminal connected to the QKDN control device 6, the information processing device 8, and the KM10 may be used.

[0219] The communication IF406 is an interface for connecting to the transmission line.

[0220] The programs executed by the QKD module 2, QKDN control device 6, information processing device 8, and KM10 of the embodiment are stored in installable or executable file format on computer-readable storage media such as CD-ROMs, memory cards, CD-Rs, and DVDs (Digital Versatile Discs) and provided as computer program products.

[0221] Alternatively, the programs executed by the QKD module 2, QKDN control device 6, information processing device 8, and KM10 may be stored on a computer connected to a network such as the Internet, and provided by being downloaded via the network.

[0222] Furthermore, the programs executed by the QKD module 2, QKDN control device 6, information processing device 8, and KM10 may be configured to be provided via a network such as the Internet without requiring downloads.

[0223] Alternatively, the programs executed by the QKD module 2, QKDN control device 6, information processing device 8, and KM10 may be pre-installed and provided in ROM or the like.

[0224] Furthermore, some or all of the functions of the QKD module 2, QKDN control device 6, information processing device 8, and KM10 may be implemented by hardware such as an IC (Integrated Circuit). The IC is, for example, a processor that performs dedicated processing.

[0225] Furthermore, when multiple processors are used to implement each function, each processor may implement one of the functions, or it may implement two or more of the functions.

[0226] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of 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 of the invention and its equivalents.

[0227] (Note) Furthermore, the above embodiments can be summarized in the following technical proposal.

[0228] Technical proposal 1 A processing unit formulates an allocation plan for distributing application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKD between opposing QKD devices included in QKDN (Quantum Key Distribution Network), to key management devices connected to each of the multiple applications via wired or wireless communication, based on the amount of application key requests from multiple applications that use the application key to encrypt or decrypt communications. A QKDN control unit equipped with the following features. Technical proposal 2 The processing unit formulates the allocation plan based on the amount of application keys required to be replenished, calculated from the requested amount of application keys and the amount of application keys previously stored in the key management device. QKDN control device as described in Technical Proposal 1. Technical proposal 3 The processing unit formulates the allocation plan based on the importance of the application's communication, according to the type of service realized by the application's communication. A QKDN control device as described in Technical Proposal 1 or 2. Technical proposal 4 The processing unit formulates the allocation plan based on the amount of link keys already shared between the opposing QKD devices and the relay path of the application keys to be transmitted via encryption relay. A QKDN control device as described in any one of Technical Proposals 1 to 3. Technical proposal 5 The processing unit determines the order in which the accumulated link keys are used, in descending order of importance, and formulates the allocation plan based on the order. QKDN control device as described in Technical Proposal 4. Technical plan 6 The processing unit determines the proportion of the accumulated link key to be used, increasing as the importance increases, and formulates the allocation plan based on the proportion. QKDN control device as described in Technical Proposal 4. Technical proposal 7 The processing unit, if the importance is equal to or greater than a predetermined importance, determines the order in which the accumulated link keys are used, in descending order of importance. If the aforementioned importance is less than the predetermined importance, the proportion of the accumulated link key used is determined to be higher the higher the importance. The allocation plan is formulated such that the encrypted relay transfer of application keys used for communication of applications whose importance is less than the predetermined importance is performed after the encrypted relay transfer of application keys used for communication of applications whose importance is equal to or greater than the predetermined importance. QKDN control device as described in Technical Proposal 4. Technical proposal 8 The processing unit formulates the distribution plan to perform encrypted relay transfer of the application keys in order of the expiration date of the application keys. A QKDN control device as described in any one of Technical Proposals 1 to 7. Technical proposal 9 A communication unit that transmits the distribution plan to a key management device connected to each of the aforementioned multiple applications by a wired or wireless communication method, A QKDN control device according to any one of the technical proposals 1 to 8, further comprising: Technical proposal 10 A communication unit receives an application key request that includes destination identification information identifying the destination of data in the application and the requested amount of the application key used to encrypt or decrypt the data, and provides the application with the requested amount of the application key. A QKDN control device according to any one of the technical proposals 1 to 9, further comprising the above. Technical proposal 11 A QKDN control device described in any one of Technical Proposals 1 to 9, Based on the aforementioned distribution plan, a plurality of key management devices encrypt and relay the application key, A plurality of QKD devices that provide the link key to a plurality of key management devices, A quantum cryptography communication system equipped with [the necessary components]. Technical proposal 12 A communication unit that sends an application key request to a key management device, which includes destination identification information that identifies the destination of the data and the requested amount of application keys used to encrypt or decrypt the data, and receives the requested amount of application keys from the key management device. The system includes a processing unit that runs an application that encrypts or decrypts the data using the aforementioned application key, The aforementioned application key is encrypted and relayed between opposing key management devices via a link key shared by the QKD between opposing QKD devices included in the QKDN (Quantum Key Distribution Network), and is distributed to key management devices connected to each of the multiple applications via wired or wireless communication, according to an allocation plan created based on the amount of the application key requested by the multiple applications. Information processing device. Technical proposal 13 A QKDN (Quantum Key Distribution Network) control unit formulates an allocation plan to distribute application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKDs between opposing QKD devices included in the QKDN, to key management devices connected to each of the multiple applications via wired or wireless communication, based on the amount of application key requests from multiple applications that use the application keys to encrypt or decrypt communications. A QKDN control method including the following. Technical proposal 14 The information processing device sends an application key request to a key management device, which includes destination identification information that identifies the destination of the data and the requested amount of application keys used to encrypt or decrypt the data, and receives the requested amount of application keys from the key management device. The information processing device operates an application that encrypts or decrypts the data using the application key. The aforementioned application key is encrypted and relayed between opposing key management devices via a link key shared by the QKD between opposing QKD devices included in the QKDN (Quantum Key Distribution Network), and is distributed to key management devices connected to each of the multiple applications via wired or wireless communication, according to an allocation plan created based on the amount of the application key requested by the multiple applications. Information processing methods. Technical proposal 15 On the computer, The QKDN (Quantum Key Distribution Network) uses link keys shared by QKD between opposing QKD devices to encrypt and relay application keys between opposing key management devices. Based on the amount of application key requests from multiple applications that use the application keys to encrypt or decrypt communications, the distribution plan is formulated to distribute these application keys to key management devices connected to each of the multiple applications via wired or wireless communication. program. [Explanation of symbols]

[0229] 1 Node 2 QKD modules 3 QKD links 4 QKD Network Controllers 5 Applications 6 QKDN Control Unit 7. User Network Control Unit 8. Information Processing Device 10 KM (key management device) 11 Communications Department 12 Storage section 13 Processing Unit 61 Communications Department 62 Storage section 63 Processing Unit 81 Communications Department 82 Memory section 83 Processing Unit 111 App Communications Department 112 Control Communication Unit 113 KM Communication Unit 131 Information Exchange Unit 132 Calculation Unit 133 Execution Unit 134 Key Processing Unit 135 Provision Unit 136 Management Unit 137 Control Unit 138 Platform Unit 139 Judgment Unit 140 Planning Unit 301 Control Device 302 Main Memory Device 303 Auxiliary Memory Device 304 Display Device 305 Input Device 306 Quantum Communication IF 307 Classical Communication IF 310 Bus / / 这里原文“バス”直译为“Bus”,但在一些专业领域可能会使用更准确的术语,比如“bus bar”(母线)等,需根据具体语境判断。这里先按要求直译为“Bus” 401 Control Device 402 Main Memory Device 403 Auxiliary Memory Device 404 Display Device 405 Input Device 406 Communication IF 410 Bus 611 KM Communication Unit 612 QKD Module Communication Unit 631 Information Collection Unit 632 Judgment Unit 633 Planning Unit 634 Management Unit 635 Control Unit 636 Platform Unit

Claims

1. A processing unit that formulates an allocation plan for distributing application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKD between opposing QKD devices included in QKDN (Quantum Key Distribution Network), to key management devices connected to each of the multiple applications via wired or wireless communication, based on the amount of application key requests from multiple applications that encrypt or decrypt communications using the application keys. A QKDN control device equipped with the following features.

2. The processing unit formulates the allocation plan based on the amount of application keys required to be replenished, calculated from the requested amount of application keys and the amount of application keys previously stored in the key management device. The QKDN control device according to claim 1.

3. The processing unit formulates the allocation plan based on the importance of the application's communication, according to the type of service realized by the application's communication. The QKDN control device according to claim 1.

4. The processing unit formulates the allocation plan based on the amount of link keys already shared between the opposing QKD devices and the relay path of the application keys to be transmitted via encryption relay. The QKDN control device according to claim 3.

5. The processing unit determines the order in which the accumulated link keys are used, in descending order of importance, and formulates the allocation plan based on the order. The QKDN control device according to claim 4.

6. The processing unit determines the proportion of the accumulated link key to be used, increasing as the importance increases, and formulates the allocation plan based on the proportion. The QKDN control device according to claim 4.

7. The processing unit, if the importance is equal to or greater than a predetermined importance, determines the order in which the accumulated link keys are used, in descending order of importance. If the aforementioned importance is less than the predetermined importance, the proportion of the accumulated link key used is determined to be higher the higher the importance. The allocation plan is formulated such that the encrypted relay transfer of application keys used for communication of applications whose importance is less than the predetermined importance is performed after the encrypted relay transfer of application keys used for communication of applications whose importance is equal to or greater than the predetermined importance. The QKDN control device according to claim 4.

8. The processing unit formulates the distribution plan to perform encrypted relay transfer of the application keys in order of the expiration date of the application keys. The QKDN control device according to claim 1.

9. A communication unit that transmits the distribution plan to a key management device connected to each of the aforementioned multiple applications by a wired or wireless communication method, The QKDN control device according to claim 1, further comprising:

10. A communication unit receives an application key request that includes destination identification information identifying the destination of data in the application and the requested amount of the application key used to encrypt or decrypt the data, and provides the application with the requested amount of the application key. The QKDN control device according to claim 1, further comprising:

11. A QKDN control device according to any one of claims 1 to 9, Based on the aforementioned distribution plan, a plurality of key management devices encrypt and relay the application key, A plurality of QKD devices that provide the link key to a plurality of key management devices, A quantum cryptography communication system equipped with [the necessary components].

12. A communication unit that sends an application key request to a key management device, which includes destination identification information that identifies the destination of the data and the requested amount of application keys used to encrypt or decrypt the data, and receives the requested amount of application keys from the key management device. The system includes a processing unit that runs an application that encrypts or decrypts the data using the aforementioned application key, The application key is encrypted and relayed between opposing key management devices via a link key shared by QKD between opposing QKD devices included in QKDN (Quantum Key Distribution Network), and is distributed to key management devices connected to each of the multiple applications via wired or wireless communication, according to an allocation plan created based on the amount of application key requests from the multiple applications. Information processing device.

13. A QKDN (Quantum Key Distribution Network) control device formulates a distribution plan to distribute application keys, which are encrypted and relayed between opposing key management devices using link keys shared by QKD between opposing QKD devices included in the QKDN, to key management devices connected to each of the multiple applications via wired or wireless communication, based on the amount of application key requests from multiple applications that use the application keys to encrypt or decrypt communications. A QKDN control method including the following.

14. The information processing device sends an application key request to a key management device, which includes destination identification information that identifies the destination of the data and the requested amount of application keys used to encrypt or decrypt the data, and receives the requested amount of application keys from the key management device. The information processing device operates an application that encrypts or decrypts the data using the application key. The application key is encrypted and relayed between opposing key management devices via a link key shared by QKD between opposing QKD devices included in QKDN (Quantum Key Distribution Network), and is distributed to key management devices connected to each of the multiple applications via wired or wireless communication, according to an allocation plan created based on the amount of application key requests from the multiple applications. Information processing methods.

15. On the computer, The QKDN (Quantum Key Distribution Network) uses link keys shared by QKD between opposing QKD devices to encrypt relay-transmit application keys between opposing key management devices. Based on the amount of application keys requested by multiple applications that use the application keys to encrypt or decrypt communications, the QKDN develops an allocation plan to distribute these application keys to key management devices connected to each of the multiple applications via wired or wireless communication. program.

Images