Key Management Device, Quantum Cryptography Communication System, and Program

Abstract

To make it possible to determine the optimal key relay path for sharing application keys in a QKD network.SOLUTION: A key management device of an embodiment is a key management device that manages an application key for encrypting communication of an application network configured by a plurality of applications. The key management device includes a collection unit, a calculation unit, a determination unit, and a communication unit. The collection unit collects resource information indicating resources of links for which a link key is generated by QKD (Quantum Key Distribution). The calculation unit calculates metrics of key relay routes including the links based on the resource information. The determination unit determines a key relay route from the plurality of key relay routes based on the metrics. The communication unit transmits the application key encrypted with the link key to a destination using the key relay route determined by the determination unit.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Embodiments of the present invention relate to a key management device, a quantum cryptographic communication system, and a program.

Background Art

[0002] In quantum key distribution (QKD), key relay path determination for sharing an application key among key management devices (KMs) in a key sharing network, that is, transfer of an application key through a plurality of KMs is performed. In a large-scale key sharing network, in order to streamline the management of the key sharing network and facilitate the management of the key sharing network, the key sharing network is generally divided into a plurality of domains.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in the conventional technology, it has been difficult to determine an optimal key relay path for sharing an application key in a QKD network.

Means for Solving the Problems

[0006] The key management device according to the embodiment is a key management device that manages an application key for encrypting communication in an application network composed of a plurality of applications. The key management device includes a collection unit, a calculation unit, a determination unit, and a communication unit. The collection unit collects resource information indicating resources of a link where a link key is generated by QKD (Quantum Key Distribution). The calculation unit calculates a metric of a key relay path including the link based on the resource information. The determination unit determines a key relay path from a plurality of key relay paths based on the metric. The communication unit transmits an application key encrypted with the link key to a destination using the key relay path determined by the determination unit.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Best Mode for Carrying Out the Invention

[0008] Embodiments of a key management device, a quantum cryptographic communication system, and a program will be described in detail below with reference to the accompanying drawings.

[0009] [Example of the Configuration of the Quantum Cryptographic Communication System] FIG. 1 is a diagram showing an example of the configuration of the quantum cryptographic communication system according to the embodiment. The quantum cryptographic communication system in FIG. 1 includes a plurality of QKD network key sharing domains (QKDN KSDs) 100-1 to 100-4 as a multi-domain key sharing network.

[0010] A plurality of KMs (key management devices) are communicably connected to each other by links and form QKDN KSDs 100-1 to 100-4. The four-digit numbers assigned to the KMs in FIG. 1 indicate identification numbers for identifying each KM. Also, the BKM indicates the KM at the boundary with an adjacent domain.

[0011] The plurality of networked KMs have a function of generating and sharing random numbers between the KMs connected by links, and a function of using the generated and shared random numbers as encryption keys (hereinafter referred to as "link keys") to perform encrypted communication on the links.

[0012] In the example of FIG. 1, the function of generating and sharing random numbers (link keys) between KMs connected by links is realized by a technology called quantum cryptography or quantum key distribution (QKD).

[0013] In addition, some of the KMs have a function of generating a cryptographic key (hereinafter referred to as "application key") that is a random number independent of the random numbers (link keys) generated between links, and a function of transmitting the application key to another KM via a link.

[0014] Each application 20 connected to each QKDN KSD100-1 to 100-4 has a function of obtaining an application key from a KM, using this as a cryptographic key, and performing encrypted communication with the application 20 at the communication destination. The encrypted communication at this time may be performed via an application network 200 different from the QKDN KSD100-1 to 100-4. For example, the Internet or the like is used for the application network 200.

[0015] For example, the KM and the application 20 are realized by one terminal. Also, for example, the KM and the application 20 may be configured as independent terminals, and the application key may be transmitted and received between the two terminals. The example of FIG. 1 shows an example when the KM and the application 20 are configured by independent terminals.

[0016] Note that the application 20 that requests the application key may be arbitrary. Also, the number of KMs, the number of key sharing domains, and the number of applications 20 are not limited to the example of FIG. 1.

[0017] Each of the QKDN KSD100-1 to 100-4 is limited, for example, within a limit value (for example, 1000) of the number of KMs and the number of links between KMs. In the example of FIG. 1, the KMs within the domain are distinguished from general KMs and B KMs at the boundary of the domain.

[0018] In the example of FIG. 1, the BKMs between domains (e.g., BKM1811, BKM1831, BKM2032, and BKM2033) are physically placed on the same trusted node (hereinafter referred to as "site"). The BKMs within the same site share information in a different way such as a local LAN connection rather than basically quantum cryptographic communication. In FIG. 1, the description of the links between the BKMs within the same site is omitted to distinguish them from the quantum cryptographic communication links.

[0019] To enhance reliability, the BKM links between domains basically consist of one or more links. For example, as shown in FIG. 1, there are two BKM links between all domains. On the other hand, from the perspective of cost savings, it is also possible to have only one BKM between domains. In this case, the information of multiple adjacent domains may be stored on one BKM.

[0020] Among multiple KMs, in the case of BKM, in addition to the information of the key sharing domain to which the BKM itself belongs, the information of the adjacent key sharing domains is also shared and stored. The adjacent BKMs share information in a way other than QKD. Also, the information stored in the BKM is assigned a sequence number in chronological order, and the information is updated according to the sequence number.

[0021] The information stored in the BKM includes, for example, path information and resource information. The path information is information regarding the routing protocol implemented as background processing. The resource information is the information used in the process of determining the key relay path for transferring the application key to the destination KM.

[0022] As a protocol (routing protocol) for determining a path (key relay path) for sharing quantum cryptographic keys through quantum key distribution within the QKDN KSD100, a communication protocol of the Interior Gateway Protocol (IGP) is used. For example, OSPF (Open Shortest Path Fast) is used as the communication protocol. OSPF uses distance (the sum of the costs of the links included in each key relay path) as a metric for performing routing (path control).

[0023] As a protocol (routing protocol) for determining a path (key relay path) for sharing quantum cryptographic keys through quantum key distribution between QKDN KSD100s, a communication protocol of the Exterior Gateway Protocol (EGP) is used. For example, BGP (Border Gateway Protocol) is used as the communication protocol. BGP is classified as a path vector type routing protocol and does not use a technical metric.

[0024] Each KM in the key sharing network (QKDN KSD100-1 to 100-4) of the quantum cryptographic communication system shares application keys. When KM encrypts and exchanges application keys with link keys, it consumes the link keys. This is because KM uses link keys as one-time pads, that is, it discards link keys that have been used once. Therefore, application keys cannot be exchanged and relayed at a rate faster than the amount of shared link keys or the speed of sharing link keys. When exchanging application keys via multiple KMs, the sharing speed of the application keys is limited by the link with the fewest link keys or the link with the lowest sharing speed of link keys. The throughput of cryptographic communication in the quantum cryptographic communication system is restricted with such a link becoming a bottleneck. Or, it becomes impossible to share application keys on a link where the link keys have been exhausted. In the quantum cryptographic communication system, it is desirable to select the best path with the fewest bottlenecks as much as possible to share application keys.

[0025] On the other hand, focusing on the consumption amount of link keys in the entire quantum cryptographic communication system, it can be said that the more links a route passes through, the greater the consumption amount of link keys. Since link keys are used when sharing application keys, they are system resources that determine the throughput of application 20 to a certain extent. Therefore, as a whole system, it is desirable to reduce the number of links passed through and suppress the consumption amount of link keys.

[0026] In a large-scale key sharing network, in order to streamline the management of the key sharing network and facilitate the management of the key sharing network, the key sharing network is generally divided into a plurality of domains (in the example of FIG. 1, QKDN KSD100-1 to 100-4). However, each domain is not limited to the same standard, the same scale, and the same quantum protocol. As a partitioning type, for example, if an upper limit is set on the number of KMs or the number of links in a domain, many KMs within the domain will have less key relay path information, and the processing time can be shortened. However, when sharing keys with KMs outside the domain, it is desirable to determine the key relay path between domains via a specific KM.

[0027] Thus, in a quantum cryptographic communication system, considering link keys as constraint resources (key resources) in the system, it is desirable to efficiently determine the key relay path within and between domains while avoiding key consumption and depletion.

[0028] Therefore, the quantum cryptographic communication system according to this embodiment determines a key relay path for suppressing the consumption of link keys as much as possible and efficiently sharing application keys. According to the quantum cryptographic communication system according to this embodiment, it is possible to reduce the consumption amount of link keys in the entire system while avoiding the depletion of link keys in a specific KM and maintaining the throughput of application key sharing.

[0029] Specifically, the quantum key distribution communication system according to this embodiment uses an algorithm for calculating resource information representing the resource of the encryption key that can be provided to the application as part of the routing protocol. As a result, since the metric for determining the key relay path is based on the resource bottleneck (the value indicating the bottleneck), the best key relay path can be determined. The quantum key distribution communication system according to this embodiment further adopts the number of hops as a metric. Thereby, a path that suppresses the consumption amount of the link key can be selected. Also, it is conceivable to add the number of hops as a metric after implementing the routing protocol.

[0030] Note that the value indicating the bottleneck is, for example, the value of the resource of the bottleneck portion. As will be described later, for example, the minimum value of the cost (resource) of each link included in the key relay path becomes the value indicating the bottleneck. Hereinafter, the value indicating the bottleneck may be simply referred to as the bottleneck.

[0031] [Example of Functional Configuration] FIG. 2 is a diagram showing an example of the functional configuration of the BKM of the embodiment. The BKM of the embodiment includes a control unit 1, a management unit 2, a platform unit 3, a communication unit 4, and a processing unit 5.

[0032] The control unit 1 controls each process performed in the BKM. For example, the control unit 1 is responsible for starting each functional unit.

[0033] The management unit 2 manages resources such as the key generation speed of the link to which the BKM is connected and the holding amount of the key used in the link.

[0034] The platform unit 3 provides functions for managing the functions on the BKM, operating system functions necessary for operation, basic network functions, and security functions.

[0035] The communication unit 4 communicates with other connected KMs (BKMs). The communication unit 4 generates and shares random numbers using quantum cryptography between the KMs (BKMs) connected by a link, and manages the generated random numbers as link keys. Also, when performing data communication with other KMs (BKMs) connected by a link, the communication unit 4 is utilized by other functional units. The data exchanged with other KMs via the communication unit includes data such as application key data. These data are usually exchanged by encrypted communication using the link keys managed by the KMs.

[0036] The processing unit 5 includes a storage unit 6, a collection unit 7, a calculation unit 8, and a determination unit 9.

[0037] The storage unit 6 includes an external information storage unit 6a and an internal information storage unit 6b. The external information storage unit 6a stores external information indicating information of a domain to which the BKM does not belong. The internal information storage unit 6b stores internal information indicating information of a domain to which the BKM belongs. Note that the external information storage unit 6a and the internal information storage unit 6b may be realized by a single storage unit 6 without being distinguished.

[0038] The information stored in the storage unit 6 is various information such as a route table, a key relay route table, and key relay route attribute information (e.g., link resource information, etc.) of each KM (BKM). For example, the storage unit 6 stores, for each KM (BKM), key relay route attribute information (e.g., key generation speed, key holding amount, and QBER) acquired from the KM (BKM).

[0039] The collection unit 7 acquires, from other KMs (BKMs), link resource information and route information that the KM (BKM) can provide. For example, the collection unit 7 also collects key relay route attribute information shared from KMs (BKMs) in other domains through the communication unit 4. For example, the collection unit 7 collects the resource information stored in the internal information storage unit 6b of other KMs (BKMs) belonging to the QKD network, and stores the resource information in the external information storage unit 6a. Also, for example, the collection unit 7 dynamically collects information on individual links.

[0040] The calculation unit 8 calculates a metric from at least one of the bottleneck and the number of hops. Further, the calculation unit 8 also calculates a state from the QBER. Details of the calculation method will be described later.

[0041] The determination unit 9 determines one key relay path (the key relay path with the best metric) based on the metric and the state within a threshold value from a plurality of key relay path candidates reaching other KMs (BKMs).

[0042] In addition to the functions of a general KM, the BKM includes a function (for example, BGP) for sharing path information with another domain and a configuration (for example, the external information storage unit 6a). Therefore, a general KM other than the BKM may not include the external information storage unit 6a. Since the configuration of the KM in the embodiment is the same as that of the BKM except for the external information storage unit 6a, the description thereof is omitted. Hereinafter, when the KM and the BKM are not distinguished, they may simply be referred to as the KM.

[0043] Each of the above units (the control unit 1, the management unit 2, the platform unit 3, the communication unit 4, the collection unit 7, the calculation unit 8, and the determination unit 9) may be realized by, for example, causing a control device such as a CPU (Central Processing Unit) to execute a program, that is, by software, or by hardware such as an IC (Integrated Circuit), or by a combination of software and hardware. Further, the storage unit 6 can be configured by any generally used storage medium such as an HDD (Hard Disk Drive), an optical disk, a memory card, and a RAM (Random Access Memory).

[0044] [Application Key Sharing Process] An example of the sharing process of the application key in QKDN KSD100-1 to 100-4 will be described. As the overall process, first, the communication unit 4 of the KM generates a link key with an adjacent KM. Next, the processing unit 5 of each KM determines a key relay path for sharing the application key with an arbitrary KM. Then, the communication unit 4 of each KM shares (transfers) the application key to the destination KM while repeatedly encrypting and decrypting with the link key at each link according to the determined path.

[0045] Next, the details of the key relay path determination process will be described. The communication unit 4 of each KM constituting QKDN KSD100-1 to 100-4 exchanges available resource information and path information with each other within the domain. Each KM calculates the resource bottleneck and the number of hops regarding the key relay path for sharing the application key with other KMs. The storage unit 6 of each KM records the QBER at the time of sharing the link key.

[0046] When the destination KM is within the domain, the determination unit 9 of each KM uses the following described algorithm with the resource bottleneck and the number of hops as metrics to avoid key depletion of links with slow key generation speed and small key holding amount, and at the same time determines a key relay path that suppresses key consumption within the domain. The BKM at the domain boundary saves the key relay path information within the domain in the internal information storage unit 6b.

[0047] Note that the avoidance of the bottleneck and the reduction of the number of hops are different metrics, and there can be several variations depending on the order and weighting for evaluating them. The determination unit 9 of the KM determines a key relay path that avoids the depletion of the link key of a certain link and suppresses key consumption within the domain by, for example, the method of (A) or (B) below.

[0048] (A) For a key relay path with the same metric [resource bottleneck], perform key relay path determination considering the metric [number of hops].

[0049] (B) Key relay path determination is performed using a single metric that takes into account both bottlenecks and the number of hops.

[0050] When a specific destination KM in application key sharing does not exist within the domain to which the source KM belongs, the communication unit 4 of the source KM requests key relay path information to the destination from each BKM within the domain to which the source KM belongs. Each BKM between domains requests key relay path information sharing of a specific destination KM to the BKM of each adjacent domain upon receiving the request. When an adjacent BKM receives a request for key relay path information to a specific destination KM, it searches for the latest key relay path information stored in its internal information storage unit 6b. If found in the internal information storage unit 6b, it returns to the BKM that requested the resource information regarding the key relay path. If not found in the internal information storage unit 6b of the adjacent BKM, the adjacent BKM continues to request the BKM of the adjacent domain. Therefore, if found, it returns to the BKM that requested the resource information regarding the key relay path to the specific destination KM within the domain to which that BKM belongs and the resource information regarding the key relay path of the domain through which it passes. Also, it is possible to set an upper limit value regarding the number of domains to pass through.

[0051] Note that the key relay path information stored in the internal information storage unit 6b is updated from the sequence number. When a BKM requests key relay path information, it shares the latest key relay path information. Also, the resource information regarding the key relay path between BKMs within each domain is stored in the external information storage unit 6a. Naturally, all key relay path information may be stored in the same storage unit 6. In the embodiment, for ease of understanding the processes within and outside the domain, the internal information storage unit 6b and the external information storage unit 6a are described separately.

[0052] Furthermore, it is assumed that a plurality of BKMs at the domain boundary are physically placed at the same location (trusted node). Also, information sharing between BKMs does not depend on the link used for key sharing.

[0053] Also, when an emergency occurs where the QBER of a link with QKDN KSD100-1 to 100-4 exceeds the specified threshold (it is determined that there is a high possibility of eavesdropping), it immediately notifies the BKM. Upon receiving the notification, the decision-making unit 9 of the BKM does not use the key relay path including that link, and the BKM at the domain boundary immediately re-determines a new path from the candidate paths.

[0054] Furthermore, it may be configured to re-execute the routing protocol and the determination process of the key relay path when a large fluctuation in resources occurs.

[0055] Note that, as an example of the metric, the resource bottleneck and the hop count of the key relay path are adopted, but other elements can also be metrics. Also, as the first element of the metric, the bottleneck is adopted, and the hop count is evaluated as the next element, but the order of evaluating these may be reversed. That is, the path determination process may be performed based on the hop count of the key relay path as the metric, and when the hop counts are equal, the bottleneck may be evaluated.

[0056] Specifically, for example, the calculation unit 8 calculates a first metric based on the resource bottleneck of a plurality of links included in the key relay path and a second metric inversely proportional to the hop count. Then, when there are a plurality of key relay paths with the same first metric, the decision-making unit 9 determines the key relay path based on the second metric. Or, when there are a plurality of key relay paths with the same second metric, the decision-making unit 9 determines the key relay path based on the first metric.

[0057] Also, it is possible to adjust the degree to which the resource bottleneck and the hop count of the key relay path are reflected in the metric. This can be achieved, for example, by weighting the resource bottleneck and the hop count of the key relay path to calculate the metric.

[0058] Taking into account the resource bottleneck is related to the speed (throughput) of sharing the application key or the avoidance of link key depletion in a certain link. Also, taking into account the number of hops is related to the overall key consumption of the system. Depending on the application adapting to the quantum cryptographic communication system, it is advisable to use the metrics appropriately.

[0059] In this embodiment, for collecting path information within the KM domain, the existing routing protocol OSPF is used, and for collecting path information between KM domains, the existing routing protocol BGP is used, but it does not exclude using other protocols.

[0060] First, the data associated with the links between each KM and its adjacent KM that make up QKDN KSD100-1 to 100-4 is as follows. The following data is assigned a sequence number in chronological order and is updated based on the sequence number.

[0061] Data associated with the link: · Cost (resource information): Link key generation speed · Cost (resource information): Link key holding amount · Status (resource information): QBER

[0062] Data associated with the KM: · Database representing the configuration within the domain (link state database) · Information on the determination of the shortest path tree to the destination KM within the domain · Information on the determination of the shortest path tree to each BKM within the domain · Bottleneck from the source to the destination KM within the domain · Number of hops from the source to the destination KM within the domain · Maximum QBER value from the source to the destination KM within the domain · Bottleneck from the source to each BKM · Number of hops from the source to each BKM · Maximum QBER value from the source to each BKM · Next Hop

[0063] The data associated with a link is resource information. The resource information includes two types of costs (the generation rate of link keys and the amount of link keys held) and the state of the link (QBER).

[0064] The key generation rate represents the speed at which link keys are shared by performing quantum key distribution between adjacent KMs. The key generation rate varies for each link due to the influence of the set parameters of the KMs connected to the link and the connection environment, etc.

[0065] The amount of keys held is the amount of keys that have not yet been used among the keys shared by performing quantum key distribution between adjacent KMs. The amount of keys held accumulates (increases) by performing quantum key distribution and is consumed (decreases) by using link keys in the application key relay between any source KM and destination KM. Note that the costs are not limited to this. For example, only the key generation rate or only the amount of keys held may be used as the cost.

[0066] Next, in order to explain the data associated with a KM, first, the method for determining the key relay path within a domain will be explained.

[0067] [Example of Method for Determining Key Relay Path within a Domain] The information necessary for determining the key relay path within a domain is collected by the following processes (1) to (4) using OSPF, which is an existing routing protocol.

[0068] (1) In OSPF, a KM sends a message called a link state update, sharing information such as the state of the links to which the KM is connected, the network address of those links, and the cost with other KMs. The link state includes information (routing information) on how a certain KM is connected to other KMs.

[0069] (2) Upon receiving a link state update, each KM grasps the network configuration within the domain based on this information. Then, a table (link state database) representing the network configuration within the domain is constructed.

[0070] (3) Each KM uses Dijkstra's algorithm from this database to calculate the shortest path tree within the domain with itself as the source, and creates a forwarding table.

[0071] (4) The internal information storage unit 6b stores the forwarding table information and resource information from a certain KM to other KMs within the domain.

[0072] The above is the basic method for determining the forwarding table within the domain in QKDN KSD100-1 to 100-4. This embodiment mainly relates to the creation of the shortest path tree within the domain in (3) among the above methods. (1), (2), and (4) can be executed by the same processing as in the prior art. However, as will be described later, a part of the information shared by the procedure in (1) includes information specific to this embodiment.

[0073] As described above, the data associated with the KM is the link state database, the confirmation information of the shortest path tree to the destination KM within the domain, the confirmation information of the shortest path tree to each BKM within the domain, the bottleneck from the source to the destination KM within the domain, the number of hops from the source to the destination KM within the domain, the maximum QBER value from the source to the destination KM within the domain, the bottleneck from the source to each BKM, the number of hops from the source to each BKM, the maximum QBER value from the source to each BKM, and the next hop.

[0074] The link state database represents the network configuration (connection relationship) within the domain, which is the information used when each KM calculates the shortest path.

[0075] The shortest path tree determination information to the destination KM within the domain indicates whether the shortest path to each destination KM within the domain is determined. If not, it means that the key relay path to that KM is only a shortest path candidate.

[0076] The shortest path tree determination information to each BKM within the domain indicates whether the shortest path to each BKM within the domain is determined. If not, it means that the key relay path to that BKM is only a shortest path candidate.

[0077] The bottleneck from the source to the destination KM within the domain represents the bottleneck of the link cost when passing through the shortest path candidate to reach the destination KM.

[0078] The hop count from the source to the destination KM within the domain represents the hop count when passing through the shortest path candidate to reach the destination KM.

[0079] The maximum QBER value from the source to the destination KM within the domain represents the maximum QBER value when passing through the shortest path candidate to reach the destination KM.

[0080] The bottleneck from the source to each BKM represents the bottleneck of the link cost when passing through the shortest path candidate to reach each BKM.

[0081] The hop count from the source to each BKM represents the hop count when passing through the shortest path candidate to reach each BKM.

[0082] The maximum QBER value from the source to each BKM represents the maximum QBER value when passing through the shortest path candidate to reach each BKM.

[0083] The next hop represents the next hop that is a candidate for the shortest path.

[0084] Each KM has a link state database, the established information as the shortest key relay path tree within the domain, the cost and state (resource information) of each link from the source KM to each other KM, the number of hops from the source to each other KM, and the next hop. The cost of each link from the source to another KM, and the number of hops from the source to another KM are maintained for each such other KM.

[0085] In the Dijkstra algorithm in OSPF, the metric was the distance. On the other hand, in the key sharing routing protocol of this embodiment, instead of the distance, the bottleneck in the key relay path is used to calculate the metric. In order to keep the key generation speed and the key holding amount between KMs sharing the application key above a certain value and prevent any obstacles to obtaining the amount of cryptographic keys required in the application network, the bottleneck is introduced as the metric.

[0086] [Example of Metric] FIG. 3A is a diagram showing Example 1 of the metric of the embodiment. FIG. 3A shows the case where the bottleneck (cost) is used as the metric. The bottleneck (cost) is calculated from the resource information including at least one of the link key generation speed in each link and the link key holding amount in each link. The calculation unit 8 calculates the metric based on the resource information.

[0087] For example, the bottleneck (cost) is calculated by the following formula. Cost link =U key +SKR×t

[0088] Here, U key represents the unused amount of the link key (remaining key amount) of each KM, SKR represents the link key generation speed of each KM, and t represents the reference time interval. The reference time interval (t) is set according to the actual situation. For example, when U key is 1000 Mbits, SKR is 3 Mbits / sec, and t is 300 sec, Cost link is 1900 (1.9 Gbits).

[0089] In FIG. 3A, the numerical values attached to each link represent costs. The minimum value of the costs of each link included in the key relay path from the source (S) via the relay (R) to the destination (D) becomes the metric (bottleneck).

[0090] In the example of FIG. 3A, since the bottleneck is the minimum value of the costs of each link included in the key relay path, min{4, 3, 6} = 3. That is, the metric (bottleneck) of the key relay path in FIG. 3A is 3.

[0091] FIG. 3B is a diagram showing Example 2 of the metric of an embodiment. FIG. 3B shows the case where the number of hops is used as the metric. The number of hops is the value of the number of relay KMs + 1. The value of the number of relay KMs + 1 included in the key relay path from the source (S) via the relay (R) to the destination (D) becomes the metric (number of hops).

[0092] In the example of FIG. 3B, since the number of hops is the number of relay KMs + 1, the number of relays included in the key relay path (2) + 1 = 3. That is, the metric (number of hops) of the key relay path in FIG. 3B is 3.

[0093] [Example of the state of the key relay path] FIG. 3C is a diagram showing an example of the state of the key relay path of an embodiment. FIG. 3C shows the case where the QBER is used for the state of the key relay path. The numerical values attached to the links represent QBER values. The maximum value of the QBERs of each link included in the key relay path from the source (S) via the relay (R) to the destination (D) becomes the state.

[0094] In the example of FIG. 3C, since the QBER is the maximum value of the states of each link included in the key relay path, min{4, 3, 6} = 6. That is, the state of this key relay path is 6.

[0095] [Example of the method for determining the key relay path] FIG. 4 is a diagram for explaining an example of a method for determining a key relay path according to an embodiment. FIG. 4 shows a method for selecting a key relay path (path) based on a metric. In FIG. 4, the source KM is represented by S, the destination KM is represented by D, and the relay KM for sharing the application key is represented by R. Also, the number assigned to the link represents the bottleneck (cost) of the link. The key relay path A has a bottleneck of 3 and a hop count of 2. The key relay path B has a bottleneck of 5 and a hop count of 3. The key relay path C has a bottleneck of 6 and a hop count of 4.

[0096] An example of a metric calculation method when the metric is calculated from the bottleneck and the hop count is shown below.

[0097] Method 1: The determination unit 9 holds the bottleneck and the hop count in separate areas. Then, the determination unit 9 gives priority to the bottleneck, and when the bottlenecks are equal, compares the hop counts and determines the path with the smaller hop count as the optimal key relay path.

[0098] Method 2: The determination unit 9 holds the bottleneck and the hop count in separate areas. Then, the determination unit 9 gives priority to the hop count, and when the hop counts are equal, compares the bottlenecks and determines the path with the larger bottleneck as the optimal key relay path.

[0099] Method 3: The determination unit 9 calculates a metric (Metric) including the bottleneck (BN) and the hop count (Hops) using a calculation formula to determine the optimal key relay path.

[0100] The calculation formula is calculated, for example, by the following formula. Metric = δ × BN + (1 - δ) × (1 / Hops)

[0101] Here, δ is a coefficient smaller than 1.

[0102] On the one hand, when the metric is only the bottleneck, the key relay path C becomes the optimal key relay path. When the metric is only the hop count, the key relay path A becomes the optimal key relay path. By setting the coefficients of the above calculation formula, it is possible to realize the case where the metric is only one of them. For example, when setting the metric to only the bottleneck, set δ = 1. Also, when setting the metric to only the hop count, set δ = 0.

[0103] Using the example of FIG. 4, an example of setting δ = 0.5 and calculating the metric according to the above method 3 will be described.

[0104] The metric of the key relay path A is Metric = 0.5×3+(1 - 0.5)×(1 / 2)=1.75. The metric of the key relay path B is Metric = 0.5×5+(1 - 0.5)×(1 / 3)=2.67. The metric of the key relay path C is Metric = 0.5×6+(1 - 0.5)×(1 / 4)=3.125.

[0105] In method 1, the bottleneck and hop count to each KM are respectively held, and the hop count is compared only when the bottlenecks are equal. In method 2, the bottleneck and hop count to each KM are respectively held, and the bottleneck is compared only when the hop counts are equal. In method 3, a calculation formula representing the metric is prepared in advance, and the metric is calculated from the bottleneck and hop count to each KM.

[0106] Note that the above calculation formula of the metric is only an example and is not limited to these. For example, other formulas may be used in which the results of adding the bottleneck and hop count with weights respectively are used as the metric. In this case, the coefficients (weights) for the bottleneck and hop count are arbitrary.

[0107] FIG. 5 is a diagram for explaining an example of a method for determining a key relay path that further considers the state of the key relay path according to the embodiment. The determination unit 9 further considers the QBER of the key relay path as a state in addition to the metrics (bottleneck and hop count). As a result, in determining the key relay path within the domain, it is possible to select a path that suppresses key consumption, and it is possible to handle the situation when an abnormality occurs, so that an efficient path selection becomes possible.

[0108] In FIG. 5, the source KM is represented by S, the destination KM is represented by D, and the relay KM for sharing the application key is represented by R. Also, the number assigned to the link represents the state of the link.

[0109] The state of the key relay path is the maximum value of the QBER of each link. As shown in FIG. 5, for example, the key relay path A has a state of 4%. The key relay path B has a state of 4%. The key relay path C has a state of 5%.

[0110] The state of the key relay path indicates the stability and safety of the key relay path. The state of the key relay path is one element for determining the key relay path. The same threshold is set for the state in each domain. If the QBER value of a certain link exceeds the threshold, it is assumed that this link is very likely to be eavesdropped. When the QBER value exceeds the threshold, the determination unit 9 determines that the key relay path including this link is unsafe, and determines a new key relay path while avoiding the link whose QBER value exceeds the threshold. The threshold is usually within 100%. For example, the threshold is set to 50%. Note that when the QBER of the avoided link returns below the threshold, the path including the link becomes a candidate for the key relay path again.

[0111] In the example of FIG. 5, the case where the application key is relayed from the source KM (S) to the destination KM (D) is shown. Based on the above method 3, the case of determining the key relay path C with the best metric will be described. For example, assume that a link with a QBER value of 5% in the key relay path C is eavesdropped, and the QBER value suddenly increases to 55%. At this time, for example, if R10, which is the relay KM, detects that the state of the key relay path C has exceeded the threshold, it feeds back to all KMs included in the key relay path C.

[0112] When the source KM (S) receives information that the state of a link in the key relay path C is abnormal, it avoids the key relay path C. Then, the determination unit 9 of the source KM (S) re-executes the determination process of the key relay path within the domain, and determines the best key relay path that does not include the above link.

[0113] As a specific operation example of each part, first, the collection unit 7 further collects state information indicating the state of the link dynamically. Next, the calculation unit 8 calculates the state information of the key relay path based on the state information of the links included in the key relay path. Then, the determination unit 9 determines the key relay path based on the metric from the key relay paths where the state information of the key relay path is smaller than the threshold, and determines that the key relay paths where the state information of the key relay path is equal to or greater than the threshold are abnormal paths.

[0114] [Example of Key Relay Path Attribute Information Stored in the Internal Information Storage Unit] FIG. 6 is a diagram showing an example of key relay path attribute information stored in the internal information storage unit 6b of the embodiment. In the example of FIG. 6, the key relay path attribute information stored in the internal information storage unit 6b of BKM1811 at the boundary of QKDN KSD100-1 will be described. The key relay path attribute information stored in the internal information storage unit 6b is information that is a candidate for the shortest path from each KM (including BKM) within the domain.

[0115] The collection unit 7 performs OSPF routing within the domain, collects key relay path attribute information to create a table, and stores the table in the internal information storage unit 6b. The information collected by the collection unit 7 includes the above metric information (bottleneck and hop count), status information (QBER), the host name of the source, and a value indicating the time of the information. Note that the information collected by the collection unit 7 may further include other information regarding the key relay path attribute information.

[0116] The key relay path attribute information shown in FIG. 6 includes a starting point (IP address), a sequence number, a bottleneck, a hop count, and a status. The starting point (IP address) is the host name of the source (e.g., IP address). The sequence number is a value indicating the time of the information (e.g., a sequence number in chronological order). The bottleneck is the bottleneck of the key relay path. The hop count is the hop count of the key relay path. The status is the status information (QBER) of the key relay path.

[0117] The collection unit 7 collects the key relay path attribute information, for example, at a predetermined time interval, and updates and discards the old key relay path attribute information based on the sequence number. For example, when the sequence number is newer (e.g., the sequence number of the received key relay path attribute information is larger than the sequence number of the key relay path attribute information being held), the key relay path attribute information that is a candidate for the shortest path is updated. Also, for example, when the sequence number is older (e.g., the sequence number of the received key relay path attribute information is smaller than the sequence number of the key relay path attribute information being held), the received key relay path attribute information is discarded as it is.

[0118] Next, a method for determining a key relay path between domains will be described.

[0119] [Example of Method for Determining Key Relay Path between Domains] When a key relay path within a domain is formed, the process of determining a key relay path between domains begins. The key relay path between domains is collected using the existing routing protocol, BGP. The KM that uses BGP is only the BKM at the boundary of the domain, not all KMs. In addition to the functions that a general KM has, the BKM includes a function for sharing information with another domain and a configuration for storing the shared information (for example, an internal information storage unit 6b and an external information storage unit 6a).

[0120] [Example of BGP-related information] FIG. 7 is a diagram showing an example of BGP-related information of an embodiment. In the example of FIG. 7, the BGP-related information stored in the external information storage unit 6a of the BKM 4325 will be described. The collection unit 7 executes the BGP routing protocol, grasps the network configuration of the domain to which the BKM 4325 belongs and the path information of the adjacent domains, and creates a path table related to BGP as the BGP-related information based on the path information.

[0121] The BGP-related information of the embodiment includes selection information, domain (IP address), next hop, domain path, and metric. Note that the BGP-related information may further include other information related to the BGP-related information.

[0122] The selection information indicates the selection state of the key relay path (BGP route). ">" indicates the route selected as the best key relay path. "*" indicates that the key relay path is a valid route (a selectable route).

[0123] The domain (IP address) indicates the prefix / mask length of the network of the destination domain. In the example of Figure 7, 1.1.1.0 / x indicates the prefix / mask length of the network of QKDN KSD100-1. 2.2.2.0 / x indicates the prefix / mask length of the network of QKDN KSD100-2. 3.3.3.0 / x indicates the prefix / mask length of the network of QKDN KSD100-3. 4.4.4.0 / x indicates the prefix / mask length of the network of QKDN KSD100-4.

[0124] The next hop is the IP address or host name of the next hop.

[0125] The domain path indicates the key relay path to the destination domain. The domain numbers passed through are listed in order from the right end. The types of routes are IBGP (Internal BGP) for routes within the domain and EBGP (External BGP) for links from other BKMs outside the domain. IBGP is indicated by "i". EBGP records the domain numbers passed through.

[0126] The metric indicates the BGP metric. The metric is calculated based on the key relay path attribute information. The calculation method is the same as that of OSPF within the domain.

[0127] In the example of Figure 7, for example, from QKDN KSD100-4, which is the domain to which BKM4325 belongs, to QKDN KSD100, there are two domain paths. The first domain path is the domain path passing through QKDN KSD100-2 (100-1,100-2,i). The second domain path is the domain path passing through QKDN KSD100-3 (100-1,100-3,i).

[0128] The domain paths (100-1, 100-2, i) marked with " * " are valid routes but not the best key relay routes. The domain path (100-1, 100-3, i) marked with " *>" is the best key relay route.

[0129] [Example of the method for sharing key relay path attribute information] The sharing of key relay path attribute information in the BKM at the domain boundary will be described. FIG. 8 is a diagram for explaining an example of the method for sharing key relay path attribute information according to the embodiment. FIG. 8 shows a basic sequence for sharing key relay path attribute information from the source KM to the destination KM outside the domain.

[0130] The process described in FIG. 8 is executed after each BKM executes the BGP routing protocol and grasps the network configuration of the domain to which the BKM belongs and the information of the BKM of the adjacent domain.

[0131] First, when KM0001 shares a key with the destination KM4666 outside the domain, the collection unit 7 of KM0001 requests all BKMs in the QKDN KSD100-1 to search for a key relay path (step S1).

[0132] Hereinafter, in the example of FIG. 8, the case where BKM1811 receives the request in step S1 will be described as an example.

[0133] Next, BKM1811 checks with BKM2032 in the adjacent QKDN KSD100-2 whether it has key relay path attribute information for the destination KM4666 (step S2). Next, BKM2032 refers to the internal information storage unit 6b and searches for key relay path attribute information for the destination KM4666 (step S3).

[0134] If the key relay path attribute information for the destination KM4666 is found in step S3, BKM2032 returns the key relay path attribute information for the destination KM4666 to BKM1811 and shares the key relay path attribute information for the destination KM4666 with BKM1811 (step S9).

[0135] In step S3, if the key relay path attribute information to the destination KM4666 is not found, BKM2032 requests the key relay path attribute information to the destination KM4666 from BKM2732 adjacent to QKDN KSD100-4 (step S4).

[0136] Next, BKM2732 checks whether the adjacent BKM4212 of QKDN KSD100-4 has the key relay path attribute information to the destination KM4666 (step S5). Next, BKM4212 refers to the internal information storage unit 6b and searches for the key relay path attribute information to the destination KM4666 (step S6).

[0137] In step S6, if the key relay path attribute information to the destination KM4666 is found, BKM2032 returns the key relay path attribute information to the destination KM4666 to BKM1811 and shares the key relay path attribute information to the destination KM4666 with BKM2732 (step S7).

[0138] Next, BKM2732 returns the key relay path attribute information to the destination KM4666 to BKM2032 and shares the key relay path attribute information to the destination KM4666 with BKM2032 (step S8).

[0139] Next, BKM2032 reads the key relay path attribute information regarding the route (the route from BKM2032 to BKM2732) within the passed QKDN KSD100-2 from the internal information storage unit 6b (step S3). Next, BKM2032 returns the key relay path attribute information found in step S6 and the key relay path attribute information read in step S3 to BKM1811 and shares the key relay path attribute information read in steps S6 and S3 with BKM1811 (step S9).

[0140] The above is the operation until BKM1811 belonging to the same domain as the source KM001 shares the key relay path attribute information.

[0141] In step S6, if the key relay path attribute information for the destination KM4666 is not found, the search process for the key relay path attribute information is repeated in the adjacent domain. The search process is continued repeatedly, for example, if the domain value indicating the number of domains passed through is within the preset upper limit value of the passed-through domains. In the example of FIG. 8, since the domain passed through is one of QKDN KSD100-2, the domain value is 1. Specifically, in the example of FIG. 8, when the upper limit value of the passed-through domain is 0, BKM2032 determines that it is impossible to reach the destination KM4666 and notifies the source BKM0001 that it is impossible to reach.

[0142] The collection unit 7 of each BKM belonging to the same domain as the source KM0001 stores all the key relay path attribute information regarding the shared path in the external information storage unit 6a. Then, the calculation unit 8 of each BKM reads the key relay path attribute information from the external information storage unit 6a and calculates the metric of the key relay path outside QKDN KSD100-1. Also, the calculation unit 8 of each BKM reads the key relay path attribute information up to the source KM0001 from the internal information storage unit 6b and calculates the metric of the key relay path within QKDN KSD100-1.

[0143] The determination unit 9 of each BKM determines one key relay path (the key relay path with the best metric) based on the state and metric of the key relay path candidates from the key relay path candidates.

[0144] Each BKM notifies the determined optimal path to the source KM0001. The source KM0001 shares the application key with the destination BKM4666 using the most appropriate path from the paths notified by each BKM.

[0145] [Example of Key Relay Path Attribute Information Stored in External Information Storage Unit] FIG. 9 is a diagram showing an example of key relay path attribute information stored in the external information storage unit 6a of the embodiment. In the example of FIG. 9, the key relay path attribute information stored in the external information storage unit 6a of BKM4325 at the boundary of QKDN KSD100-4 will be described. The key relay path attribute information stored in the external information storage unit 6a is information that is a candidate for the shortest path from each KM (including BKM) outside the domain.

[0146] The collection unit 7 collects key relay path attribute information outside the domain, creates a table, and stores the table in the external information storage unit 6a. Since the information collected by the collection unit 7 is the same as that in FIG. 6, the description thereof will be omitted.

[0147] Note that the key relay path attribute information for BKMs at physically the same site is the same. In the example of FIG. 9, the destination BKM1831 in the first row and the destination BKM2033 in the third row belong to different domains but are physically at the same site, so the key relay path attribute information is the same.

[0148] [Example of Key Relay Path Determination Process] FIG. 10 is a flowchart showing an example of the key relay path determination process of the embodiment. A case where a key relay path from a source KM to a destination KM in a domain different from the source domain is determined will be described as an example.

[0149] First, the collection unit 7 of the BKM (hereinafter referred to as the "source BKM") belonging to the same domain as the source KM executes the OSPF routing protocol for the intra-domain and the BGP routing protocol for the inter-domains to grasp the network configuration, and then collects the key relay path attribute information from the source KM to the source BKM (step S21).

[0150] The key relay path attribute information collected in step S21 is represented by the following formula (1).

[0151]

Equation

[0152] Here, Cost link represents the cost (resource) of each link between KMs. The resource is the key generation rate and the key holding amount. QBER link represents the QBER (state) of each link between KMs. KSD links represents a set including m links.

[0153] Next, the calculation unit 8 of the source BKM calculates the key relay path attribute information (cost, hop count, and state) within the domain (from the source KM to the source BKM) (step S22). Specifically, the calculation unit 8 of the source BKM calculates the bottleneck of the cost collected in step S21 according to the following formula (2), calculates the maximum value of the QBER (state) collected in step S21 according to the following formula (3), and calculates the hop count (the total value of the links passed through + 1) according to the following formula (4).

[0154]

Number

Number

Number

[0155] The cost (bottleneck) within the domain (from the source KM to the source BKM) is Cost KSD and the state (QBER) is Status KSD and the hop count is H KSD and it becomes like this.

[0156] Next, the calculation unit 8 of the source BKM calculates the metric and status of the key relay path (step S23). Specifically, first, the source BKM requests the BKM of the adjacent domain KSD2 for the key relay path attribute information to the destination KM. If the BKM of the adjacent domain KSD2 stores the key relay path attribute information to the destination KM in the internal information storage unit 6b, the cost (Cost KSD2 ), status (Status KSD2 ), and hop count (H KSD2 ) within the adjacent domain KSD2 are sent to the source BKM.

[0157] If the key relay path attribute information to the destination KM is not stored in the internal information storage unit 6b of the BKM of the adjacent domain KSD2, the BKM of the adjacent domain KSD2 continuously requests the key relay path attribute information to the destination KM from the further adjacent domain KSD3. At this time, the key relay path attribute information to the BKM2 at the same site as the BKM3 of the adjacent domain needs to be shared with the source BKM.

[0158] Next, the calculation unit 8 of the source BKM combines the key relay path attribute information to the destination KM outside the domain (KSD2~KSD n ) and the key relay path attribute information from the source KM to the source BKM within the domain (KSD1), and calculates the metric (M path ) and status (Status path ).

[0159] As an example of the calculation of the metric (M path ), first, the calculation unit 8 of the source BKM calculates the cost (Cost path ) of the key relay path using the following formula (5), calculates the hop count (H path ) of the key relay path using the following formula (6), and then calculates the metric (M path ) using the following formula (7).

[0160]

Equation

Equation

Number

[0161] Note that μ is a coefficient indicating weight.

[0162] Also, the state (Status path ) is calculated by the following formula (8).

[0163]

Number

[0164] Note that when there are multiple key relay paths path1, ···, path from the source KM to the destination KM outside the domain in the external information storage unit 6a of the BKM j , the key relay path attribute information regarding all the key relay paths path1, ···, path j is stored.

[0165] Finally, the determination unit 9 of the source BKM determines the optimal key relay path from among the multiple key relay paths path1, ···, path from the source KM to the destination KM in response to the request of the source KM to share the application key (step S24). Specifically, the determination unit 9 of the source BKM determines the optimal key relay path based on, for example, the following formulas (9) and (10). j That is, the determination unit 9 of the source BKM determines the optimal key relay path based on, for example, the following formulas (9) and (10).

[0166]

Number

Number

[0167] The status value of the path (Status route ) is a parameter representing the security of the path, and a path with a status value within the threshold is a candidate for the optimal key relay path.

[0168] Note that the processing of steps S21 and S22 described above is an example, and the collection and calculation of cost, hop count, and status may be performed by other methods. For example, for each KM passed through, the cost and status may be continuously compared, and when the passed KM holds the minimum value of the cost up to that KM and the maximum value of the status, the minimum value of the cost and the maximum value of the status may be transmitted to the BKM. In this case, at the BKM, the minimum value of the cost up to the BKM and the maximum value of the status are collected. Also, the hop count is the cumulative value of the passed KMs.

[0169] [Example of Determining Key Relay Path] FIG. 11 is a diagram showing an example of determining a key relay path according to an embodiment. When sharing a key from the source KM (KM0001) in QKDN KSD100-1 to the destination KM (KM4666) in the right-side QKDN KSD100-4, the BKM collection unit 7 collects key relay path attribute information (for example, bottleneck, hop count, and status value). Then, the BKM calculation unit 8 stores the information calculated based on the key relay path attribute information in the external information storage unit 6a of the BKM.

[0170] For example, when sharing a key via KDN KSD100-2 to KDN KSD100-4, the bottleneck becomes 90. When sharing a key via KDN KSD100-3 to KDN KSD100-4, the bottleneck becomes 80. As shown in FIG. 11, when there are a plurality of paths 1 to 3, the BKM determination unit 9 determines the optimal path for sharing the key according to the request (definition of metric).

[0171] Note that resources can vary, for example, when quantum key distribution is executed and the key holdings increase, or when the key holdings decrease by transferring application keys, or when the key generation rate or the state value changes due to the influence of environmental changes in the quantum encryption device or the like. Therefore, when detecting fluctuations in resources, the collection unit 7 may re-execute the routing protocol including the operations of this embodiment and recalculate the optimal key relay path. For example, when the communication unit 4 receives a notification of an abnormal change in the state value (the state value of the path exceeds the threshold), the determination unit 9 promptly re-determines the optimal path from the paths without such abnormal changes (candidate paths with state values within the threshold).

[0172] When such a situation is not preferable, the source node can send the key using the source routing method and specify in advance the key relay path for sending the key, so that the key relay path determined by the source node can be selected. Source routing is a method in which the source determines the key relay path through which the data should pass and transfers the data along the determined key relay path.

[0173] In addition, the path control according to this embodiment is applicable to methods other than the method of encrypting and sharing application keys with link keys.

[0174] As described above, the key management devices (KM, BKM) of the embodiment are key management devices that manage application keys for encrypting the communication of an application network 200 composed of a plurality of applications 20. The key management device includes a collection unit 7, a calculation unit 8, a determination unit 9, and a communication unit 4. The collection unit 7 collects resource information indicating the resources of the links where link keys are generated by QKD. The calculation unit 8 calculates the metric of the key relay path including the link based on the resource information. The determination unit 9 determines the key relay path based on the metric from among a plurality of key relay paths. The communication unit 4 transmits the application key encrypted with the link key to the destination using the key relay path determined by the determination unit 9.

[0175] According to the key management devices (KM, BKM) of the embodiments, in a QKD network, an optimal key relay path for sharing an application key can be determined. Specifically, according to the key management devices (KM, BKM) of the embodiments, for example, even in a QKD network divided into a plurality of domains, consumption of link keys can be suppressed as much as possible, and a key relay path for efficiently sharing an application key can be determined. Thereby, while avoiding depletion of link keys in a specific KM and maintaining throughput, it becomes possible to reduce the consumption amount of link keys in the entire system. Further, by the collection unit 7 collecting the state information of the path, re-determination of the path at the time of an abnormality can also be efficiently executed.

[0176] (Modification Example 1) Next, Modification Example 1 of the embodiment will be described. In the description of Modification Example 1, descriptions similar to those of the embodiment will be omitted, and differences from the embodiment will be described.

[0177] FIG. 12 is a diagram for explaining Modification Example 1 of the embodiment. In Modification Example 1, a server device (QKD controller 30) for centrally managing the key relay paths of each domain (QKDN KSD100) is further provided.

[0178] The QKD controller 30 may specify a key relay path for sharing a key with the destination KM. The QKD controller 30 calculates the best key relay path and reflects the calculated key relay path in the key relay path tables of each KM (including BKM). Thereby, each KM can select the best key relay path.

[0179] (Modification Example 2) Next, Modification Example 2 of the embodiment will be described. In the description of Modification Example 2, descriptions similar to those of the embodiment will be omitted, and differences from the embodiment will be described.

[0180] FIG. 13 is a diagram for explaining Modification Example 2 of the embodiment. In Modification Example 2, there are QKD controllers 30-1 to 30-4 for each domain (QKDN KSD100-1 to 100-4). The key relay path attribute information is collected between adjacent QKD controllers 30, and the QKD controller 30 determines the optimal path from the source KM to the destination KM and reflects it in the key relay path table of the KM (including BKM).

[0181] Each QKD controller 30 preferably manages information by dividing it into an internal information storage unit 6b and an external information storage unit 6a, similar to the BKM in the embodiment. Also, information is shared between QKD controllers 30 by a method other than quantum key distribution (QKD). The configuration example of this Modification Example 2 has a centralized-to-centralized configuration.

[0182] (Modification Example 3) Next, Modification Example 3 of the embodiment will be described. In the description of Modification Example 3, the same explanations as in the embodiment will be omitted, and the parts different from the embodiment will be described.

[0183] FIG. 14 is a diagram for explaining Modification Example 3 of the embodiment. Modification Example 3 is an example of a configuration in which a so-called distributed type and a centralized type are mixed. In Modification Example 3, the information sharing between the QKD controller 30 and the BKM is via the BKM (centralized BKM) of the domain (QKDN KSD100-2) to which the QKD controller 30 belongs, as shown on the left side of the figure. This centralized BKM does not include a routing protocol function or the like.

[0184] Also, from the viewpoint of ease of management and cost savings, as shown on the right side of FIG. 14, in the distributed type, BKM3111 may be set as the primary BKM, and BKM3333 may be set as the secondary BKM that operates instead when the primary BKM is abnormal (a combined type of the centralized type of QKD controller 30 and the distributed type of BKM).

[0185] [Example of Hardware Configuration] FIG. 15 is a diagram showing an example of the hardware configuration of the KM, BKM, and QKD controller 30 of the embodiment. The KM, BKM, and QKD controller 30 of the embodiment includes a control device such as a CPU (Central Processing Unit) 301, a storage device such as a ROM (Read Only Memory) 302 and a RAM (Random Access Memory) 303, and a communication I / F 304 that connects to a network to perform communication. The CPU) 301, ROM 302, RAM 303, and the network are connected by a bus 305.

[0186] For example, the program executed by the KM, BKM, and QKD controller 30 according to the present embodiment is provided by being pre-incorporated in a ROM or the like.

[0187] Also, for example, the program executed by the KM, BKM, and QKD controller 30 according to the present embodiment may be configured to be recorded on a computer-readable recording medium such as a CD-ROM (Compact Disk Read Only Memory), a flexible disk (FD), a CD-R (Compact Disk Recordable), and a DVD (Digital Versatile Disk) in an installable format or an executable format file, and provided as a computer program product.

[0188] Furthermore, the program executed by the KM, BKM, and QKD controller 30 according to the present embodiment may be configured to be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. Also, the program executed by the KM, BKM, and QKD controller 30 according to the present embodiment may be configured to be provided or distributed via a network such as the Internet. The program executed by the KM, BKM, and QKD controller 30 according to this embodiment can cause a computer to function as each part of the KM, BKM, and QKD controller 30 described above. This computer can read a program from a computer-readable storage medium into the main storage device and execute it by the CPU.

[0189] Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalent scope thereof.

Explanation of Reference Numerals

[0190] 1 Control Unit 2 Management Unit 3 Platform Unit 4 Communication Unit 5 Processing Unit 6 Storage Unit 6a External Information Storage Unit 6b Internal Information Storage Unit 7 Collection Unit 8 Calculation Unit 9 Decision Unit 20 Application 30 QKD Controller 100 QKDN KSD 200 Application Network 301 CPU 302 ROM 303 RAM 304 Communication I / F 305 Bus

Claims

1. A key management device for managing an application key that encrypts communication in an application network composed of a plurality of applications, The key management device, A collection unit that collects resource information indicating resources of a link where a link key is generated by QKD (Quantum Key Distribution); A calculation unit that calculates a metric of a key relay path including the link based on the resource information; A determination unit that determines a key relay path based on the metric from a plurality of key relay paths; A communication unit that transmits an application key encrypted with the link key to a destination using the key relay path determined by the determination unit, and The resource information includes a generation rate of the link key in the link and an amount of the link key held in the link, The calculation unit calculates a first metric based on a bottleneck of resource information of a plurality of links included in the key relay path, The bottleneck is a value based on costs of the plurality of links, The cost of the link is a weighted sum of the generation rate of the link key in the link and the amount of the link key held, The determination unit determines the key relay path using the first metric as the metric, Key management device.

2. A key management device for managing an application key that encrypts communication in an application network composed of a plurality of applications, The key management device, A collection unit that collects resource information indicating resources of a link where a link key is generated by QKD (Quantum Key Distribution); A calculation unit that calculates a metric of a key relay path including the link based on the resource information; A determining unit that determines a key relay path from a plurality of key relay paths based on the metric; A communication unit that transmits an application key encrypted by the link key to a destination using the key relay path determined by the determining unit. The calculating unit further calculates the number of hops of the key relay path, and calculates the metric based on the number of hops. The calculating unit calculates a first metric based on a bottleneck of resource information of a plurality of links included in the key relay path, and a second metric inversely proportional to the number of hops. When there are a plurality of key relay paths with the same first metric, the determining unit determines a key relay path based on the second metric. A key management device.

3. A key management device for managing an application key for encrypting communication in an application network composed of a plurality of applications, The key management device includes: A collection unit that collects resource information indicating resources of links where link keys are generated by QKD (Quantum Key Distribution); A calculating unit that calculates a metric of a key relay path including the link based on the resource information; A determining unit that determines a key relay path from a plurality of key relay paths based on the metric; A communication unit that transmits an application key encrypted by the link key to a destination using the key relay path determined by the determining unit. The calculating unit further calculates the number of hops of the key relay path, and calculates the metric based on the number of hops. The calculating unit calculates a first metric based on a bottleneck of resource information of a plurality of links included in the key relay path, and a second metric inversely proportional to the number of hops. When there are multiple key relay paths with the same second metric, the determination unit determines a key relay path based on the first metric further. Key management device. **Claim 4** A key management device for managing an application key for encrypting communication in an application network composed of a plurality of applications, The key management device belongs to any one of a plurality of domains included in the QKD network, The key management device is A collection unit that collects resource information indicating a resource of a link on which a link key is generated by QKD (Quantum Key Distribution); A calculation unit that calculates a metric of a key relay path including the link based on the resource information; A determination unit that determines a key relay path based on the metric from a plurality of key relay paths; A communication unit that transmits an application key encrypted by the link key to a destination using the key relay path determined by the determination unit; An internal information storage unit that stores internal information indicating information of a domain to which the key management device belongs; An external information storage unit that stores external information indicating information of a domain to which the key management device does not belong, and The internal information includes at least the resource information of the link included in the domain to which the key management device belongs, The external information includes at least the resource information of the link included in the domain to which the key management device does not belong. Key management device. **Claim 5** The collection unit further collects status information indicating the status of the link, The calculation unit calculates the status information of the key relay path based on the status information of the links included in the key relay path. The determining unit determines a key relay path based on the metric from a key relay path whose state information of the key relay path is smaller than a threshold value, and determines that a key relay path whose state information of the key relay path is equal to or greater than the threshold value is an abnormal path. The key management device according to any one of claims 1 to 4.

6. The state information of the link is the QBER (Quantum Bit Error Rate) of the link. The key management device according to claim 5.

7. The collecting unit collects the resource information stored in the internal information storage unit of another key management device belonging to the QKD network. The external information storage unit stores the resource information stored in the internal information storage unit of the other key management device. The key management device according to claim 4.

8. A quantum cryptographic communication system including a plurality of key management devices, The plurality of key management devices manage an application key for encrypting communication of an application network composed of a plurality of applications, The key management device includes: A collecting unit that collects resource information indicating a resource of a link in which a link key is generated by QKD (Quantum Key Distribution); A calculating unit that calculates a metric of a key relay path including the link based on the resource information; A determining unit that determines a key relay path based on the metric from a plurality of key relay paths; A communication unit that transmits an application key encrypted by the link key to a destination using the key relay path determined by the determining unit. The resource information includes a generation rate of the link key in the link and an amount of the link key held in the link. The calculation unit calculates a first metric based on the bottleneck of the resource information of a plurality of links included in the key relay path. The bottleneck is a value based on the costs of the plurality of links. The cost of the link is a weighted sum of the generation rate of the link key and the holding amount of the link key in the link. The determination unit determines the key relay path using the first metric as the metric. Quantum cryptographic communication system. **Claim 9**: A quantum cryptographic communication system including a plurality of key management devices, wherein the plurality of key management devices manage application keys for encrypting communication of an application network composed of a plurality of applications, the key management device belongs to any one of a plurality of domains included in the QKD network, the key management device, a collection unit that collects resource information indicating resources of a link in which a link key is generated by QKD (Quantum Key Distribution); a calculation unit that calculates a metric of a key relay path including the link based on the resource information; a determination unit that determines a key relay path from a plurality of key relay paths based on the metric; a communication unit that transmits an application key encrypted by the link key to a destination using the key relay path determined by the determination unit; an internal information storage unit that stores internal information indicating information of a domain to which the key management device belongs; an external information storage unit that stores external information indicating information of a domain to which the key management device does not belong, and the internal information includes at least the resource information of the links included in the domain to which the key management device belongs, the external information includes at least the resource information of the links included in the domain to which the key management device does not belong. Quantum cryptography communication system.

10. A computer that manages an application key for encrypting communication in an application network composed of multiple applications, collects resource information indicating the resources of a link where a link key is generated by QKD (Quantum Key Distribution), calculates the metric of a key relay path including the link based on the resource information, determines a key relay path from multiple key relay paths based on the metric, causes the application key encrypted by the link key to be transmitted to a destination using the determined key relay path, The resource information includes the generation rate of the link key in the link and the holding amount of the link key in the link. calculates a first metric based on the bottleneck of the resource information of multiple links included in the key relay path, The bottleneck is a value based on the cost of the multiple links, The cost of the link is the weighted sum of the generation rate of the link key in the link and the holding amount of the link key, determines the key relay path using the first metric as the metric, Program.

11. A computer that manages an application key for encrypting communication in an application network composed of multiple applications, collects resource information indicating the resources of a link where a link key is generated by QKD (Quantum Key Distribution), calculates the metric of a key relay path including the link based on the resource information, determines a key relay path from multiple key relay paths based on the metric, Cause the application key encrypted by the link key to be transmitted to the destination using the determined key relay path. Further calculate the number of hops of the key relay path, and calculate the metric based on the number of hops. Calculate a first metric based on the bottleneck of the resource information of a plurality of links included in the key relay path, and a second metric inversely proportional to the number of hops. When there are a plurality of key relay paths with the same first metric, determine the key relay path based on the second metric. Program.

12. On a computer that manages an application key for encrypting communication in an application network composed of a plurality of applications, Collect resource information indicating the resources of the links where link keys are generated by QKD (Quantum Key Distribution). Calculate the metric of the key relay path including the link based on the resource information. Determine a key relay path from a plurality of key relay paths based on the metric. Cause the application key encrypted by the link key to be transmitted to the destination using the determined key relay path. Further calculate the number of hops of the key relay path, and calculate the metric based on the number of hops. Calculate a first metric based on the bottleneck of the resource information of a plurality of links included in the key relay path, and a second metric inversely proportional to the number of hops. When there are a plurality of key relay paths with the same second metric, determine the key relay path based on the first metric. Program.

13. Manage an application key for encrypting the communication of an application network composed of a plurality of applications, and to a computer belonging to any of a plurality of domains included in the QKD network, Collect resource information indicating a link resource for which a link key is generated by QKD (Quantum Key Distribution), Calculate a metric of a key relay path including the link based on the resource information, Determine a key relay path from a plurality of key relay paths based on the metric, Cause the application key encrypted by the link key to be transmitted to a destination using the determined key relay path, Cause internal information indicating information of the domain to which the computer belongs to be stored in an internal information storage unit, Cause external information indicating information of a domain to which the computer does not belong to be stored in an external information storage unit, The internal information includes at least the resource information of the link included in the domain to which the computer belongs, The external information includes at least the resource information of the link included in the domain to which the computer does not belong, Program.

Images