Information processing device, quantum cryptographic communication system, information processing method, and computer program product
The information processing device enhances QKD network security by controlling the decryption and encryption of encryption keys using local keys, reducing the time application keys are in plaintext, thus minimizing the risk of information leakage during key relays.
Patent Information
- Application Number
- JP2024037152
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-03-11
- Publication Date
- 2025-09-25
AI Technical Summary
Conventional quantum key distribution (QKD) systems face challenges in enhancing the security of encryption keys stored and managed within devices, particularly during key relay processes, where application keys are temporarily in plaintext, increasing the risk of information leakage.
An information processing device that includes a first processing unit to control the decryption and encryption of encrypted second encryption keys, utilizing a local key for secure key relay, minimizing the time application keys are in plaintext by employing consecutive, simultaneous, or sequential decryption and encryption processes.
This approach significantly reduces the risk of application key leakage by ensuring that encryption keys are processed in an encrypted form within the key management device, thereby enhancing the security of key relays in quantum cryptography networks.
Smart Images

Figure 2025138206000001_ABST
Abstract
Description
[Technical Field]
[0001] An embodiment of the present invention relates to an information processing device, a quantum cryptography communication system, an information processing method, and a program. [Background technology]
[0002] Quantum Key Distribution (QKD) is a technology for securely sharing keys for encrypted data communication between a QKD transmitter that continuously transmits single photons and a QKD receiver that receives the single photons, connected via optical fiber. Based on the principles of quantum mechanics, the keys shared by QKD are guaranteed to be resistant to eavesdropping. In principle, QKD key sharing is limited in communication distance and can only be performed one-to-one. A QKD network (QKDN) can be configured by introducing a key management (KM) device in addition to the QKD device, where the KM holds and manages the keys and relays them. This enables encryption key sharing between any two locations in a network with QKD as the link and KM as the node. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-171530 [Non-patent literature]
[0004] [Non-Patent Document 1] ITU-T Y.3800, [online], [searched on February 7, 2020], Internet <URL: https: / / www.itu.int / rec / T-REC-Y.3800 / en> Summary of the Invention [Problem to be solved by the invention]
[0005] However, with conventional technology, it has been difficult to further improve the security of encryption keys stored and managed within the device. [Means for solving the problem]
[0006] An information processing device according to an embodiment is an information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network. The information processing device according to the embodiment includes a first processing unit that determines a forwarding destination of a received packet and then controls execution of decryption of the encrypted second encryption key included in the packet. [Brief explanation of the drawings]
[0007] [Figure 1] A diagram showing the concept of a QKD network. [Figure 2] FIG. 2 is a diagram showing an example of a communication device configuration at locations A, B, and C in FIG. [Figure 3] FIG. 3 is a diagram showing an example of operation when KM2B in FIG. 2 serves as a relay point for key relay. [Figure 4] A diagram showing an example of operation when KM2B in Figure 2 is the end point of key relay. [Figure 5] A diagram showing an example of operation when KM2B in Figure 2 is the starting point of key relay. [Figure 6] FIG. 6 is a diagram illustrating the three cases of FIGS. 3 to 5 together. [Figure 7] FIG. 4 is a diagram for explaining a section in which a plaintext application key exists in KM2B in FIG. 3. [Figure 8] FIG. 5 is a diagram for explaining a section in which a plaintext application key exists in KM2B in FIG. 4. [Figure 9] FIG. 6 is a diagram for explaining a section in which a plaintext application key exists in KM2B in FIG. 5; [Figure 10] FIG. 10 is a diagram illustrating the three cases of FIGS. 7 to 9 collectively. [Figure 11] FIG. 2 is a diagram showing an example of the functional configuration of a KM according to the first embodiment. [Figure 12]FIG. 2 is a diagram for explaining a functional block of nftables (iptables) corresponding to a first processing unit in the first embodiment. [Figure 13] FIG. 10 is a diagram showing an example of the operation of a KM according to the first embodiment (when transferring an application key). [Figure 14] FIG. 10 is a diagram showing an example of the operation of a KM according to the first embodiment (when receiving an application key). [Figure 15] FIG. 10 is a diagram showing an example of the operation of a KM according to the first embodiment (when transmitting an application key). [Figure 16] FIG. 16 is a diagram illustrating the three cases of FIGS. 13 to 15 collectively. [Figure 17] 10 is a flowchart showing an example of the operation of the KM (when transferring an application key) in the first embodiment. [Figure 18] 10 is a flowchart showing an example of the operation of the KM (when receiving an application key) in the first embodiment. [Figure 19] 10 is a flowchart showing an example of the operation of the KM (when transmitting an application key) in the first embodiment. [Figure 20] 10 is a flowchart showing an example of the operation of the KM (when transferring an application key) in the second embodiment. [Figure 21] 11 is a flowchart showing an example of the operation of a KM according to the third embodiment (when transferring an application key). [Figure 22] FIG. 2 is a diagram showing an example of the hardware configuration of the QKD device according to the first to third embodiments. [Figure 23] FIG. 2 is a diagram showing an example of the hardware configuration of a key management device according to the first to third embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0008] Hereinafter, embodiments of an information processing device, a quantum cryptography communication system, an information processing method, and a program will be described in detail with reference to the accompanying drawings.
[0009] 1 is a diagram showing the concept of a QKD network 100. As described above, a QKD device 1 executes the QKD protocol with a counterpart QKD device 1 via QKD to generate an encryption key (hereinafter referred to as a "local key").
[0010] The local key (first encryption key) is an encryption key shared between QKD devices 1 by QKD. The local key is provided to a key management device 2 (hereinafter referred to as "KM2") connected within a site. The local key is used by KM2 to encrypt or decrypt an application key.
[0011] KM2 receives local keys from one or more QKD devices 1. KM2 stores and manages cryptographic keys (local keys and application keys), and relays application keys between KM2s, enabling cryptographic key sharing between any two KM2s. Key relaying is described in more detail below.
[0012] An application key (hereinafter referred to as "application key") is a random number generated by KM2 using a random number generator or the like. The application key (second encryption key) is encrypted and decrypted by KM2 using a local key, and is then relayed (transferred) between KM2s, allowing it to be shared between any number of locations. The application key is provided by KM2 to an application (not shown) and used for encrypted communication. An application connects to KM2, obtains the application key from KM2, and performs encrypted communication with another application. An application is usually installed at the same location as the KM2 to which it is connected. Multiple applications may be connected to one KM2.
[0013] Points A to E are locations where the QKD device 1 and KM 2 are installed. The points are assumed to be areas where physical security is ensured, thereby guaranteeing the security of the storage and relay of cryptographic keys.
[0014] It should be noted that the QKD device 1 and KM2 may be realized as a single entity and may be called a trusted node.
[0015] Fig. 2 is a diagram showing an example of the communication device configuration at points A, B, and C in Fig. 1. In the example of Fig. 2, KMs 2A, 2B, and 2C are installed at points A, B, and C, respectively. Furthermore, QKD device 1A is installed at point A, QKD devices 1B-1 and 1B-2 are installed at point B, and QKD device 1C is installed at point C.
[0016] QKD is performed between QKD device 1A and QKD device 1B-1 and between QKD device 1B-2 and QKD device 1C, local keys are generated, and the local keys are provided to KMs 2A to 2C within points A to C, respectively.
[0017] KM2A transfers the application key encrypted with the local key shared between QKD device 1A and QKD device 1B-1 to KM2B. Similarly, KM2B transfers the application key encrypted with the local key shared between QKD device 1B-2 and QKD device 1C to KM2C.
[0018] Hereinafter, the basic operation of key relay will be explained using Figures 3 to 6, taking the device configuration in Figure 2 as an example. Figures 3 to 6 focus on KM2B and show the case where it is the relay point of key relay (Figure 3), the case where it is the end point of key relay (Figure 4), the case where it is the start point of key relay (Figure 5), and a summary of the three cases (Figure 6).
[0019] 3 is a diagram showing an example of operation in the case where the KM2B in FIG. 2 serves as a relay point for the key relay. The KM2A includes a key management unit 21, a storage unit 22, a transfer processing unit 23, and a network IF (Interface) processing unit 24.
[0020] The key management unit 21 generates an application key. The key management unit 21 generates the application key by using a random number generator such as a QRNG (Quantum Random Number Generation) or the like. The key management unit 21 also provides the application key to an application via a wired or wireless communication IF.
[0021] The storage unit 22 mainly manages and stores application keys. The storage unit 22 may also manage and store local keys. The storage unit 22 is realized by, for example, a combination of a main storage device such as a ROM (Read Only Memory) and a RAM (Random Access Memory), and an auxiliary storage device such as a HDD (Hard Disk Drive) and a memory card.
[0022] The key management unit 21, the transfer processing unit 23, and the network IF processing unit 24 are realized by at least one processing unit. This processing unit includes, for example, a control unit and an arithmetic unit, and is realized by an analog or digital circuit, etc. 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.
[0023] The forwarding processing unit 23 processes packets (communication packets) according to the routing table information. For example, the forwarding processing unit 23 controls the processing (sending, receiving, and forwarding) of packets that include data indicating an application key.
[0024] The network IF processing unit 24 transmits and receives packets. The network IF processing unit 24 also encrypts and decrypts application keys using a local key. The local key used for encryption and decryption by the KM 2A is provided by the QKD device 1A.
[0025] The network IF processing unit 24 may manage and store the local key. The number of network IF processing units 24 provided is equal to the number of network IFs that can transfer the application key. Therefore, as in the example of KM2B in FIG. 3, one KM2 may include multiple network IF processing units 24.
[0026] FIG. 3 shows a case in which an application key is generated by KM2A, KM2B relays the application key, KM2C receives the application key, and as a result, KM2A and KM2C share the application key.
[0027] The key management unit 21 of KM2A generates an application key, and the storage unit 22 manages and stores the application key. The generated application key is passed to the transfer processing unit 23 for processing. Specifically, the packet header and other settings are set based on the destination information for the application key, and the destination network IF is determined. The packet containing data indicating the application key is passed to the network IF processing unit 24 corresponding to the destination determined by the transfer processing unit 23. The network IF processing unit 24 encrypts the packet containing data indicating the application key using a local key corresponding to the destination network IF, and transfers the encrypted application key from KM2A to KM2B.
[0028] When the network IF processor 24-1 of the KM2B receives the encrypted application key, it decrypts the encrypted application key using the local key corresponding to the network IF.
[0029] Next, the transfer processing unit 23 processes the packet containing the decrypted application key. Specifically, the transfer processing unit 23 determines the transfer destination (send destination) of the packet by referencing destination information, etc., indicated in the packet header. The packet containing the application key data is passed to the network IF processing unit 24-2 corresponding to the send destination determined by the transfer processing unit 23. The network IF processing unit 24-2 encrypts the packet containing data indicating the application key using a local key corresponding to the network IF of the send destination, and transfers the encrypted application key from KM2B to KM2C.
[0030] When the network IF processing unit 24 of the KM 2C receives the encrypted application key, it decrypts the encrypted application key using the local key corresponding to the network IF.
[0031] Next, the transfer processing unit 23 processes the packet containing the decrypted application key. Specifically, the transfer processing unit 23 references the destination information and the like indicated in the packet header, identifies that the destination is KM2C, and performs reception processing of the packet. As a result, the storage unit 22 holds (manages) the received application key.
[0032] Through the above processing, the application key is shared between KM2A and KM2C.
[0033] Next, we will explain Figure 4.
[0034] Fig. 4 is a diagram showing an example of operation when KM2B in Fig. 2 is the end point of key relay. Fig. 4 shows a case where an application key is generated by KM2A, KM2B receives the application key, and as a result, the application key is shared between KM2A and KM2B.
[0035] The key management unit 21 of KM2A generates the application key, and the storage unit 22 also manages and stores the application key. The generated application key is passed to the transfer processing unit 23 for processing. Specifically, the packet header and other settings are set based on the destination information of the application key, and the destination network IF is determined. The packet containing data indicating the application key is passed to the network IF processing unit 24 corresponding to the destination determined by the transfer processing unit 23. The network IF processing unit 24 encrypts the packet containing data indicating the application key using a local key corresponding to the destination network IF, and transfers the encrypted application key from KM2A to KM2B.
[0036] When the network IF processor 24-1 of the KM2B receives the encrypted application key, it decrypts the encrypted application key using the local key corresponding to the network IF.
[0037] Next, the transfer processing unit 23 processes the packet containing the decrypted application key. Specifically, the transfer processing unit 23 references the destination information etc. indicated in the packet header, identifies that KM2B is the destination, and performs reception processing of the packet. As a result, the storage unit 22 holds (manages) the received application key.
[0038] Through the above processing, the application key is shared between KM2A and KM2B.
[0039] Next, FIG. 5 will be described.
[0040] Fig. 5 is a diagram showing an example of operation when KM2B in Fig. 2 is the starting point of key relay. Fig. 5 shows a case where an application key is generated by KM2B, KM2C receives the application key, and as a result, the application key is shared between KM2B and KM2C.
[0041] The key management unit 21 of KM2B generates the application key, and the storage unit 22 also manages and stores the application key. The generated application key is passed to the transfer processing unit for processing. Specifically, the packet header and other settings are set based on the destination information of the application key, and the destination network IF is determined. The packet containing data indicating the application key is passed to the network IF processing unit 24 corresponding to the destination determined by the transfer processing unit 23. The network IF processing unit 24 encrypts the packet containing the data indicating the application key using a local key corresponding to the destination network IF, and transfers the encrypted application key from KM2B to KM2C.
[0042] When the network IF processing unit 24 of the KM 2C receives the encrypted application key, it decrypts the encrypted application key using the local key corresponding to the network IF.
[0043] Next, the transfer processing unit 23 processes the packet containing the decrypted application key. Specifically, the transfer processing unit 23 references the destination information and the like indicated in the packet header, identifies that the destination is KM2C, and performs reception processing of the packet. As a result, the storage unit 22 holds (manages) the received application key.
[0044] Through the above processing, the application key is shared between KM2B and KM2C.
[0045] Next, FIG. 6 will be described.
[0046] Fig. 6 is a diagram that collectively shows the three cases of Fig. 3 to Fig. 5. That is, focusing on KM2B, it shows three cases: a case in which it transfers (relays) an application key, a case in which it is the destination of the application key (a case in which it is the end point of the application key data), and a case in which it is the transmission source of the application key (a case in which it is the start point of the application key data).
[0047] Here, the storage unit 22 of the KM2B holds (manages) application keys that have been generated with the KM2B as the sender and application keys that have been received with the KM2B as the destination.
[0048] As described above, the network IF processing unit 24-1 decrypts the received application key using the local key and passes it to the transfer processing unit 23. Furthermore, the network IF processing unit 24-2 receives the application key to be transmitted from the transfer processing unit 23, encrypts it using the local key, and transmits it.
[0049] The transfer processing unit 23 of the KM2B receives, relays, and transmits packets that include data indicating the application key.
[0050] When receiving, the transfer processing unit 23 obtains the application key from the packet received from the network IF processing unit 24-1 and stores the application key in the storage unit 22.
[0051] When transmitting, the transfer processing unit 23 transfers the application key read from the storage unit 22 to the network IF processing unit 24-2.
[0052] When relaying, the transfer processing unit 23 passes the packet received from the network IF processing unit 24-1 to the network IF processing unit 24-2.
[0053] The forwarding processing unit 23 determines the delivery process (forwarding process) of these packets by referring to a routing table.
[0054] 7 to 10 are diagrams illustrating FIGS. 3 to 6 again, focusing on KM2B, to explain the interval in which a plaintext application key exists.
[0055] Fig. 7 is a diagram illustrating a section in which a plaintext application key exists in KM2B in Fig. 3. In the case of Fig. 7, when network IF processing unit 24-1 receives an encrypted application key from an external source, it uses decryption processing unit 25 to decrypt the application key using a local key.
[0056] Network IF processing unit 24-1 passes the plaintext application key to transfer processing unit 23. Next, transfer processing unit 23 identifies the transfer destination by referencing information such as the header of the packet containing the application key, and passes the plaintext application key to network IF processing unit 24-2.
[0057] The network IF processor 24-2 uses the encryption processor 26 to encrypt the application key using the local key, and transmits the encrypted application key to the outside.
[0058] At this time, the application key received from the outside and the application key sent to the outside are encrypted with the local key. On the other hand, the application key passed from the network IF processing unit 24-1 to the transfer processing unit 23, the application key being processed by the transfer processing unit 23, and the application key passed from the transfer processing unit 23 to the network IF processing unit 24-2 are not encrypted and are in plain text.
[0059] Fig. 8 is a diagram illustrating a section in which a plaintext application key exists in KM2B in Fig. 4. In the case of Fig. 8, when network IF processing unit 24-1 receives an encrypted application key from an external source, it uses decryption processing unit 25 to decrypt the application key using a local key.
[0060] The network IF processing unit 24-1 passes the plaintext application key to the transfer processing unit 23. Next, the transfer processing unit 23 references information such as the header of the packet containing the application key, identifies that the transfer destination of the application key is KM2B, performs reception processing of the packet, and stores the application key in the storage unit 22.
[0061] At this time, the application key received from outside is encrypted with the local key. On the other hand, the application key passed from the network IF processing unit 24-1 to the transfer processing unit 23, the application key being processed by the transfer processing unit 23, and the application key passed from the transfer processing unit 23 to the storage unit 22 are not encrypted and are in plain text.
[0062] It should be noted that the application key can be encrypted and stored in the storage unit 22.
[0063] 9 is a diagram illustrating a section in which a plaintext application key exists in KM2B in FIG.
[0064] Next, the transfer processing unit 23 assembles a packet header and the like from the destination information of the application key, etc. Furthermore, the transfer processing unit 23 references the information in the packet header and the like to identify the transfer destination of the application key, and passes the plaintext application key to the network IF processing unit 24-2.
[0065] The network IF processor 24-2 uses the encryption processor 26 to encrypt the application key using the local key, and transmits the encrypted application key to the outside.
[0066] At this time, the application key transmitted to the outside is encrypted with the local key. On the other hand, the application key passed from the storage unit 22 to the transfer processing unit 23, the application key being processed by the transfer processing unit 23, and the application key passed from the transfer processing unit 23 to the network IF processing unit 24-2 are not encrypted and are in plain text.
[0067] It should be noted that the application key can be encrypted and stored in the storage unit 22.
[0068] Fig. 10 is a diagram illustrating the three cases of Fig. 7 to Fig. 9. Combining the three cases described in Fig. 7 to Fig. 9, the application key in plaintext exists in the section shown in Fig. 10.
[0069] As described above, the KM2 securely shares application keys between any two locations (between KM2s) by transferring application key data in a form encrypted with a local key. However, the application keys passed between the network IF processing unit 24 and the transfer processing unit 23, the application keys being processed by the transfer processing unit 23, and the application keys passed between the transfer processing unit 23 and the storage unit are in plaintext.
[0070] Therefore, to safely relay the application key, it is essential to operate each base (all bases, including the base that is the start point of the application key transfer, the relay base, and the terminal base) securely. If an attacker were to infiltrate a base and then KM2, or if an attacker were to be present inside a base, the application key passed between the network IF processing unit 24 and the transfer processing unit 23, the application key being processed by the transfer processing unit 23, and the application key passed between the transfer processing unit 23 and the storage unit 22 could be referenced by memory reference or the like, which could lead to information leakage.
[0071] Therefore, in order to ensure secure operation of the base and to prepare for attacks from within the base, it is desirable that application keys be processed in encrypted form, even within KM2, and not in plain text whenever possible.
[0072] In QKDN, a node that performs key relay performs the following processes: (1) decrypting the application key using a local key, (2) transferring the application key, and (3) encrypting the application key using a local key. From the time the application key is decrypted using a local key until it is encrypted using the local key, the application key is (temporarily) stored in plaintext at the node. Although this is only the short time it takes for the node to perform transfer processing, it is necessary to use physical security technology, memory encryption technology, etc. in conjunction with the key to ensure its safety and security.
[0073] In a conventional key relay at a node on a QKDN, when an application key is received, it is decrypted using a local key during network interface processing, and when an application key is sent, it is encrypted using a local key during network interface processing. Therefore, as described above, there are a small number of situations in which the application key exists in plaintext on the system during the application key transfer process.
[0074] (First embodiment) Therefore, in the first embodiment described below, the following two processes are performed during the transfer process (a specific example is the forward process in iptables / nftables on a Linux OS): (1) decryption of the application key using a local key required for application key reception, and (2) encryption of the application key using a local key required for application key transfer (transmission). These processes are performed (A) consecutively, (B) before encryption, or (C) simultaneously. This effectively reduces the time that the application key is held in plaintext during key relay. This makes it possible to minimize the risk of application key leakage due to an intrusion attack on a node that performs key relay.
[0075] [Example of functional configuration] 11 is a diagram showing an example of the functional configuration of KM2-2 in the first embodiment. KM2-2 in the first embodiment includes a key management unit 21, a storage unit 22, a first processing unit 27, and a second processing unit 28. The explanation of the key management unit 21 and the storage unit 22 is omitted as it is the same as the explanation of FIG. 3 above.
[0076] The first processing unit 27 and the second processing unit 28 are realized by at least one processing unit. The first processing unit 27 and the second processing unit 28 are realized by, for example, two processing units. The processing unit includes, for example, a control unit and an arithmetic unit, and is realized by analog or digital circuits, etc. The processing unit may be a central processing unit (CPU), a general-purpose processor, a microprocessor, a digital signal processor (DSP), an ASIC, an FPGA, or a combination thereof.
[0077] The first processing unit 27 includes an input packet route determining unit 271 , an input packet processing unit 272 , a forwarding packet processing unit 273 , an output packet route determining unit 274 , and an output packet processing unit 275 .
[0078] The second processing unit 28 performs a transmission process to transmit a packet including the encrypted application key (second encryption key) to another KM 2-2 via the network IF. The second processing unit 28 includes network IF processing units 281-1 and 281-2, and an encryption / decryption processing unit 282.
[0079] Hereinafter, when there is no need to distinguish between the network IF processing units 281-1 and 281-2, they will simply be referred to as the network IF processing unit 281. Note that, although the example in Fig. 11 shows two network IF processing units 281-1 and 281-2, any number of network IF processing units 281 may be used. In other words, a network IF processing unit 281 may exist corresponding to any number of network IFs provided in KM2-2.
[0080] The functional configuration of the first processing unit 27 described above corresponds to the functions of a transfer processing unit (IP Layer and Bridge Layer) implemented as iptables or nftables in the Linux (registered trademark) operating system, for example.
[0081] FIG. 12 is a diagram for explaining the functional blocks of nftables (iptables) corresponding to the first processing unit 27 of the first embodiment. Referring to FIG. 12, the correspondence between the internal components of the first processing unit 27 and the hook functions (implementations) of nftables / iptables is shown below.
[0082] <When corresponding to transfer (IP routing) at the IP layer> Input packet route determination unit 271: Corresponds to prerouting hook and routing decision. Input packet processing unit 272: Corresponds to input hook. Transfer packet processing unit 273: Corresponds to forward hook. Output packet route determination unit 274: Corresponds to routing decision and output hook. Output packet processing unit 275: Corresponds to postrouting hook.
[0083] <When corresponding to transfer (bridging) at layer 2> Input packet route determination unit 271: Corresponds to prerouting bridge and routing decision. Input packet processing unit 272: Corresponds to input bridge. Transfer packet processing unit 273: Corresponds to forward bridge. Output packet route determination unit 274: Corresponds to output bridge. Output packet processing unit 275: Corresponds to postrouting bridge.
[0084] Note that the above correspondence shows the functional positioning correspondence for reference, and does not mean that each process of the internal components of the first processing unit 27 is the same as the process of the functional blocks in FIG. 11.
[0085] <Functional configuration of the first processing unit> 11, the input packet route determination unit 271 receives a packet including data indicating an encrypted application key from the network IF processing unit 281-1 and determines the destination of the packet. If the destination is KM2-2, the packet is forwarded to the input packet processing unit 272. If the destination is not KM2-2, the packet is forwarded to the forwarding packet processing unit 273.
[0086] This determination is made by referencing the destination address written in the packet header and the routing table held by KM2-2. If the destination address matches the address of KM2-2, the packet is determined to be destined for KM2-2 and is forwarded to the input packet processor 272. If the destination address does not match KM2-2, the packet is forwarded to the forwarding packet processor 273.
[0087] When a received packet is addressed to KM2-2, the input packet processor 272 processes the encrypted application key included in the packet. When the input packet processor 272 receives a packet containing an encrypted application key from the input packet route determiner 271, the input packet processor 272 uses the encryption / decryption processor 282 to decrypt the application key and stores the application key in the storage unit 22.
[0088] That is, when the transfer destination is its own device, the input packet processing unit 272 controls the execution of decryption of the encrypted application key (second encryption key) included in the packet, and then performs input processing to store the decrypted application key in the storage unit 22. The input packet processing unit 272 performs this input processing using the input hook function in iptables or nftables.
[0089] The forwarding packet processing unit 273 performs decryption and encryption of the encrypted application key using the encryption / decryption processing unit 282. When the forwarding destination is another KM2-2, the forwarding packet processing unit 273 performs decryption and encryption processing using the packet forwarding hook function in iptables or nftables. The processing by the forwarding packet processing unit 273 is the most distinctive feature of the first embodiment, and details of the processing will be described later.
[0090] The output packet route determination unit 274 reads the application key from the storage unit 22 and determines the destination of the packet containing data indicating that application key. This determination is made by referencing the destination address written in the packet header and the routing table held by KM 2-2. The network IF processing unit 281 that is the output destination varies depending on the determination result. The packet whose destination has been determined is transferred to the output packet processing unit 275.
[0091] That is, when transmitting an application key (second encryption key) generated by the random number generator in the key management unit 21 to another KM 2-2, the output packet route determination unit 274 performs output processing to control the encryption of the application key generated by the random number generator after determining the destination of the packet containing the application key generated by the random number generator and before transmission processing by the second processing unit 28. The output packet route determination unit 274 performs this output processing using the output hook function in iptables or nftables.
[0092] The output packet processor 275 processes packets to be transmitted externally. The output packet processor 275 uses the encryption / decryption processor 282 to encrypt the application key using a local key corresponding to the network IF determined by the output packet route determiner 274. The output packet processor 275 then transfers the packet including data indicating the encrypted application key to, for example, the network IF processor 282-2.
[0093] <Functional configuration of the second processing unit> The network IF processing unit 281 transfers packets containing data indicating the encrypted application key between the outside and the first processing unit 27.
[0094] The encryption / decryption processing unit 282 is used by the input packet processing unit 272, the forwarding packet processing unit 273, and the output packet processing unit 275, and encrypts and decrypts data indicating an application key. When used by the input packet processing unit 272, the encryption / decryption processing unit 282 decrypts data indicating an application key. When used by the forwarding packet processing unit 273, the encryption / decryption processing unit 282 encrypts and decrypts data indicating an application key. When used by the output packet processing unit 275, the encryption / decryption processing unit 282 encrypts data indicating an application key.
[0095] The keys used for encryption and decryption are local keys. Local keys are managed collectively as a key ring for each QKD device 1 to which KM2-2 is connected. The physical storage location of the local keys does not matter.
[0096] When the encryption / decryption processing unit 282 is used by the input packet processing unit 272, it determines which key ring to use to decrypt the data indicating the application key, based on the source address of the packet or information about the network IF that received the packet.
[0097] The key set may be determined by the input packet processor 272 or the encryption / decryption processor 282 .
[0098] When used by the output packet processing unit 275, the encryption / decryption processing unit 282 determines which key ring to use to encrypt data indicating an application key, based on the destination address of the packet or information about the network IF that sends the packet.
[0099] The key set may be determined by the output packet processor 275 or the encryption / decryption processor 282 .
[0100] When encryption / decryption processing unit 282 is used by transfer packet processing unit 273, it determines which set of keys to use to decrypt data indicating an application key based on the source address of the packet or information about the network IF that received the packet. Also, encryption / decryption processing unit 282 determines which set of keys to use to encrypt data indicating an application key based on the destination address of the packet or information about the network IF that sends the packet.
[0101] The key set may be determined by the transfer packet processing unit 273 or the encryption / decryption processing unit 282.
[0102] Next, an example of the operation of the KM2-2 in the first embodiment will be described with reference to FIGS.
[0103] Fig. 13 is a diagram showing an example of the operation of the KM 2-2 in the first embodiment (when transferring an application key). Fig. 13 shows a case in which the KM 2-2 in the first embodiment transfers an application key received from an external device to the external device (relays the application key).
[0104] First, network IF processing unit 281-1 receives a packet including data indicating an encrypted application key. Network IF processing unit 281-1 transfers the packet as is to first processing unit 27 without decrypting it. In first processing unit 27, input packet route determination unit 271 receives this packet.
[0105] The input packet route determining unit 271 determines that the destination of the application key is a destination different from the address of KM2-2, and transfers the packet to the transfer packet processing unit 273.
[0106] The transfer packet processing unit 273 uses the encryption / decryption processing unit 282 to decrypt the encrypted application key and to encrypt the decrypted application key.
[0107] The encryption / decryption processing unit 282 uses a local key to encrypt and decrypt data indicating the application key. The set of local keys used for decryption is identified based on the source address of the packet or information on the network IF that received the packet. The set of local keys used for encryption is identified based on the destination address of the packet or information on the network IF that sends the packet.
[0108] The packet containing the data indicating the encrypted application key is passed from the forwarding packet processing unit 273 to the network IF processing unit 281-2, and is forwarded from the network IF processing unit 281-2 to the outside.
[0109] The above process realizes relaying of an encrypted application key. In the example of Fig. 13 described above, when relaying (transferring) an application key, the data indicating the application key is decrypted and encrypted not by network IF processing unit 281 but by first processing unit 27. As a result, when relaying the application key, the data indicating the application key becomes plaintext only inside transfer packet processing unit 273.
[0110] 14 is a diagram showing an example of operation of the KM 2-2 in the first embodiment (when receiving an application key). Fig. 14 shows a case in which the KM 2-2 in the first embodiment receives an application key from an external device and receives it at the KM 2-2 (becoming the end point of the key relay).
[0111] First, network IF processing unit 281-1 receives a packet including data indicating an encrypted application key. Network IF processing unit 281-1 transfers the packet as is to first processing unit 27 without decrypting it. In first processing unit 27, input packet route determination unit 271 receives this packet.
[0112] The incoming packet route determination unit 271 determines that the destination of the application key is the address of KM2-2, and transfers the packet to the incoming packet processing unit 272. The incoming packet processing unit 272 uses the encryption / decryption processing unit 282 to decrypt the application key.
[0113] The encryption / decryption processing unit 282 uses a local key to decrypt data indicating the application key. The set of local keys used for decryption is identified based on the source address of the packet or information on the network IF that received the packet. The decrypted data indicating the application key is passed from the input packet processing unit 272 to the storage unit 22 and stored in the storage unit 22.
[0114] Through the above process, the relay of the encrypted application key is terminated. In the example of Fig. 14 described above, when the application key is received, the data indicating the application key is decrypted not by network IF processing unit 281-1 on the receiving side but by incoming packet processing unit 272. As a result, the data indicating the application key becomes plaintext when the application key is received only when incoming packet processing unit 272 stores the application key in storage unit 22.
[0115] Fig. 15 is a diagram showing an example of the operation of the KM 2-2 in the first embodiment (when transmitting an application key). Fig. 15 shows a case in which the KM 2-2 in the first embodiment generates an application key and transmits the application key (becoming the starting point of the application key relay).
[0116] The output packet route determination unit 274 reads the application key generated by the key management unit 21 from the storage unit 22. The output packet route determination unit 274 identifies the destination of the application key and transfers a packet including data indicating the application key to the output packet processing unit 275. The output packet processing unit 275 uses the encryption / decryption processing unit 282 to encrypt the data indicating the application key.
[0117] The encryption / decryption processing unit 282 uses a local key to encrypt data indicating the application key. The set of local keys used for encryption is identified based on the destination address of the packet or information about the network IF that sends the packet. The packet containing the encrypted data indicating the application key is passed from the output packet processing unit 275 to the network IF processing unit 281-2, and then transferred from the network IF processing unit 281-2 to an external device.
[0118] Through the above process, relaying of the encrypted application key begins. In the example of Fig. 15 described above, when the application key is transmitted, the data indicating the application key is encrypted not by network IF processing unit 281-2 on the transmitting side but by output packet processing unit 275. As a result, when the application key is transmitted, the data indicating the application key is in plain text only in the section from storage unit 22 to output packet processing unit 275.
[0119] FIG. 16 is a diagram illustrating the three cases illustrated in FIGS. 13 to 15. The relaying (transferring, receiving, or transmitting) of the application key by KM 2-2 described above can be summarized as shown in FIG. 16. Referring to FIG. 16, the key points and effects of the first embodiment will be reaffirmed. As shown in FIG. 16, when relaying the application key, the data indicating the application key is decrypted or encrypted not by the network IF processing unit 281 on the sending side or the receiving side, but by the transfer packet processing unit 273, the input packet processing unit 272, or the output packet processing unit 275. As a result, when relaying the application key, the data indicating the application key becomes plaintext only inside the first processing unit 27.
[0120] This also shortens the period within KM2-2 where data indicating the application key that should be encrypted and stored exists in plain text, further strengthening data security within the base that stores the application key.
[0121] Next, a method for decrypting and encrypting data indicating an application key when the application key is transferred (relayed) according to the first embodiment will be described in detail with reference to FIG.
[0122] Fig. 17 is a flowchart showing an example of the operation of the KM 2-2 (when transferring an application key) in the first embodiment. The example in Fig. 17 shows the case of "sequential processing" in which decryption processing and encryption processing are performed consecutively.
[0123] In a second embodiment described later, a "reverse order process" in which decryption and encryption processes are performed in reverse order will be described. In a third embodiment described later, a "simultaneous process" in which decryption and encryption processes are performed simultaneously will be described.
[0124] The "sequential processing" method will be described with reference to Figure 17. First, network IF processing unit 281-1 receives a packet including data indicating an encrypted application key (step S1). In the case of transferring (relaying) an application key, the packet received in step S1 is input to transfer packet processing unit 273 by input packet route determination unit 271.
[0125] Next, the forwarding packet processing unit 273 identifies the forwarding destination of the packet (the transmission network IF that transmits the packet) from the destination address of the packet (an example of destination information) (step S2).
[0126] Next, the forwarding packet processing unit 273 identifies the set of keys (first set of keys) to be used to decrypt the data indicating the application key from the network IF that received the packet (step S3). Note that the first set of keys may be identified using the source address of the packet.
[0127] Next, the transfer packet processing unit 273 controls the execution of decryption of the application key using the local key of the first key ring before transmission processing by the second processing unit 28. The transfer packet processing unit 273 instructs the encryption / decryption processing unit 282 to decrypt the application key. Then, the encryption / decryption processing unit 282 decrypts the data indicating the application key using the local key obtained from the first key ring (step S4).
[0128] Next, the transfer packet processing unit 273 identifies a set of keys (second set of keys) to be used for encrypting data indicating the application key from the transmission network IF identified in step S2 (step S5).
[0129] Next, the transfer packet processing unit 273 controls the execution of encryption of the application key using the local key of the second key ring before the transmission process by the second processing unit 28. The transfer packet processing unit 273 instructs the encryption / decryption processing unit 282 to encrypt the application key. Then, the encryption / decryption processing unit 282 encrypts data indicating the application key using the local key obtained from the second key ring (step S6).
[0130] Next, the network IF processor 281-2 transfers a packet including data indicating the encrypted application key (step S7).
[0131] By using the "continuous processing" method in FIG. 17, the transfer packet processing unit 273 executes the decryption process and the encryption process of the application key consecutively, so that the application key data exists as plaintext only during the interval (time) between the decryption process and the encryption process.
[0132] Next, a method for decrypting data indicating an application key when the application key is received according to the first embodiment will be described in detail.
[0133] 18 is a flowchart showing an example of operation of the KM 2-2 (when receiving an application key) in the first embodiment. First, the network IF processing unit 281-1 receives a packet including data indicating an encrypted application key (step S11).
[0134] Next, the input packet route determination unit 271 identifies that the destination of the packet received in step S11 is its own device (step S12). The input packet received in step S11 is input to the input packet processing unit 272 by the input packet route determination unit 271.
[0135] Next, the incoming packet processor 272 identifies the set of keys (first set of keys) to be used to decrypt the data indicating the application key from the network IF that received the packet (step S13). Note that the first set of keys may be identified using the source address of the packet.
[0136] Next, the encryption / decryption processing unit 282 decrypts the data indicating the application key using the local key acquired from the first key ring (step S14). Next, the input packet processing unit 272 stores the application key decrypted in step S14 in the storage unit 22 (step S15).
[0137] Next, a method for encrypting data indicating an application key when the application key is transmitted according to the first embodiment will be described in detail.
[0138] 19 is a flowchart showing an example of operation of the KM 2-2 in the first embodiment (when transmitting an application key). First, the output packet route determination unit 274 reads data indicating the application key from the storage unit 22 and identifies the destination of a packet containing the data indicating the application key (the transmission network IF that transmits the packet) (step S21). The destination of the application key is determined by the key management unit 21, for example, as a sharing destination of the application key.
[0139] Next, the output packet route determination unit 274 identifies a set of keys (second set of keys) to be used for encrypting data indicating the application key from the network IF that transmits the packet (step S22). Note that the second set of keys may be identified using the destination address of the packet.
[0140] Next, the encryption / decryption processing unit 282 encrypts data indicating the application key using the local key acquired from the second key ring (step S23).
[0141] Next, the network IF processor 281-2 transmits a packet including data indicating the encrypted application key (step S24).
[0142] As described above, KM2-2 (an example of an information processing device) in the first embodiment relays an application key (second encryption key) encrypted with a local key (first encryption key) shared with the opposing QKD device 1 included in the QKD network 100. After determining the forwarding destination of a received packet, the first processing unit 27 of KM2-2 controls the execution of decryption of the encrypted second encryption key included in the packet.
[0143] As a result, according to the first embodiment, it is possible to further improve the security of the encryption key that is held and managed in the device within the base.
[0144] (Second embodiment) Next, a second embodiment will be described. In the description of the second embodiment, the same explanation as in the first embodiment will be omitted, and only differences from the first embodiment will be described. In the second embodiment, a "reverse order process" will be described, in which the decryption process and encryption process are performed in reverse order as a method for decrypting and encrypting data indicating an application key when the application key is transferred (relayed).
[0145] Fig. 20 is a flowchart showing an example of the operation of KM2-2 in the second embodiment (when transferring an application key). The "reverse order processing" method will be described with reference to Fig. 20. Steps S31 to S33 are the same as steps S1 to S3 in the first embodiment, so their description will be omitted.
[0146] The forwarding packet processing unit 273 identifies the set of keys (second set of keys) used to encrypt the data indicating the application key from the transmission network IF identified in step S32 (step S34).
[0147] Next, the transfer packet processing unit 273 controls the execution of encryption of the application key using the local key of the second key ring before transmission processing by the second processing unit 28. The transfer packet processing unit 273 instructs the encryption / decryption processing unit 282 to encrypt the application key. Then, the encryption / decryption processing unit 282 encrypts data indicating the application key using the local key acquired from the second key ring (step S35). Here, the encryption method is assumed to be the OTP (One-time Pad) method.
[0148] Next, the transfer packet processing unit 273 controls the execution of decryption of the application key using the local key of the first key set before transmission processing by the second processing unit 28. The transfer packet processing unit 273 instructs the encryption / decryption processing unit 282 to decrypt the application key. Then, the encryption / decryption processing unit 282 decrypts the data indicating the application key using the local key acquired from the first key set (step S36). Here, the decryption method is assumed to be the OTP method.
[0149] Next, the network IF processor 281-2 transfers a packet including data indicating the application key encrypted using the second key ring and the local key acquired from the first key ring (step S37).
[0150] In the second embodiment, by using the "reverse order processing" method of FIG. 20, data indicating the application key is encrypted before being decrypted in the transfer packet processing unit 273, and then decrypted. OTP is used as the encryption and decryption method. OTP performs an XOR (Exclusive OR) operation on data indicating the application key and data indicating the local key. Therefore, there is no difference in the resulting data whether decryption is performed before encryption or encryption is performed after decryption. In other words, the order of encryption and decryption is not important.
[0151] According to the second embodiment, even inside the forwarding packet processing unit 273, there is no section (time) where data indicating the application key exists as plaintext.
[0152] (Third embodiment) Next, a third embodiment will be described. In the description of the third embodiment, the same explanation as in the second embodiment will be omitted, and only differences from the second embodiment will be described. In the third embodiment, a "simultaneous process" in which decryption and encryption processes are performed simultaneously will be described as a method for decrypting and encrypting data indicating an application key when the application key is transferred (relayed).
[0153] Fig. 21 is a flowchart showing an example of the operation of KM2-2 in the third embodiment (when transferring an application key). The "simultaneous processing" method will be described with reference to Fig. 21. Steps S41 to S44 are the same as steps S31 to S34 in the second embodiment, so their description will be omitted.
[0154] The transfer packet processing unit 273 controls the simultaneous execution of decryption and encryption of the application key before transmission processing by the second processing unit 28. The transfer packet processing unit 273 instructs the encryption / decryption processing unit 282 to decrypt and encrypt the application key. The encryption / decryption processing unit 282 then performs an XOR operation on the local key acquired from the first key set and the local key acquired from the second key set to generate a local key (transfer local key) to be used for encrypting data indicating the application key (step S45).
[0155] Next, the encryption / decryption processing unit 282 performs a process of both decryption and encryption on the data indicating the application key using the local key for transfer (third encryption key) generated in step S45 (step S46). As a result of the process in step S46, the data indicating the application key becomes encrypted using the local key obtained from the second key ring.
[0156] Next, the network IF processor 281-2 transfers a packet including data indicating the application key encrypted using the local key obtained from the second key ring (step S47).
[0157] In the third embodiment, by using the "simultaneous processing" method in FIG. 21 , data representing an application key is simultaneously decrypted and encrypted by conversion using a local key for transfer in the transfer packet processing unit 273. OTP is used as the encryption and decryption method. OTP performs an XOR operation on data representing an application key and data representing a local key. Therefore, even if the local key to be applied to an application key is XOR-operated in advance, there is no difference in the resulting data.
[0158] According to the third embodiment, even inside the forwarding packet processing unit 273, there is no section (time) where data indicating the application key exists as plaintext.
[0159] As described above, according to the methods of decrypting and encrypting data indicating an application key during transfer in the first to third embodiments, the period (time) during which the application key that should be encrypted and stored is stored as plaintext within KM2-2 is minimized (in the case of the first embodiment). In the cases of the second and third embodiments, the period (time) during which the application key is stored as plaintext is eliminated, further strengthening the security of concealing the data indicating the application key.
[0160] The methods for decrypting and encrypting data indicating an application key in the first to third embodiments (the three methods of "sequential processing," "reverse order processing," and "simultaneous processing") are independent. In practice, one of these embodiments is used to decrypt and encrypt the application key to be transferred (relayed).
[0161] (Variation) Next, a description will be given of variations of the above-described first to third embodiments. In the above-described first to third embodiments, the relay, reception, and transmission for relaying packets including data indicating an application key have been described.
[0162] In this modification, KM2-2 communicates packets other than those containing data indicating the application key. Packets unrelated to the application key do not need to be encrypted and decrypted as described in the first to third embodiments.
[0163] In a modified example, for such irrelevant packets, the encryption and decryption described in the first to third embodiments above are not applied by identifying the packet to be processed based on, for example, the packet's protocol number, port number, address information, etc.
[0164] That is, in this modification, only packets that are subject to application key relay are decrypted and encrypted by applying the above-described first to third embodiments, and packets that are not subject to application key relay are subjected to conventional packet processing (specifically, IP routing or bridging).
[0165] One method for realizing the operation of the modified example is to apply a packet filter rule before the input packet route determination unit 271 determines whether the destination of a packet including data indicating an application key is its own device, etc. Specifically, the input packet route determination unit 271 processes only packets that match the filter rule, and excludes packets that do not match the filter rule, and does not perform the encryption and decryption described in the first to third embodiments.
[0166] Such a filter rule can be realized by, for example, iptables (nftables). For example, the first processing unit 27 determines packets to be subjected to decryption processing or encryption processing based on a filter setting by iptables or nftables.
[0167] According to this modification, filter rules can be used to exclude, for example, ICMP packets and network management packets from encryption and decryption using the local key, preventing adverse effects on communications other than those for application key relay. This also prevents the local key from being consumed more than necessary.
[0168] Finally, an example of the hardware configuration of the QKD device 1 and the key management device (KM) 2-2 according to the first to third embodiments will be described.
[0169] [Example of hardware configuration] 22 is a diagram showing an example of the hardware configuration of the QKD device 1 of the first to third embodiments. The QKD device 1 of the first to third embodiments includes a control device 301, a main memory device 302, an auxiliary memory device 303, a display device 304, an input device 305, a quantum communication IF 306, and a classical communication IF 307.
[0170] The control device 301 , the main memory device 302 , the auxiliary memory device 303 , the display device 304 , the input device 305 , the quantum communication IF 306 and the classical communication IF 307 are connected via a bus 310 .
[0171] The control device 301 executes a program read from the auxiliary storage device 303 to the main storage device 302. The main storage device 302 is a memory such as a ROM and a RAM. The auxiliary storage device 303 is a HDD, a memory card, or the like.
[0172] The display device 304 displays the status of the QKD device 1, etc. The input device 305 accepts input from the user. The display device 304 and the input device 305 may be realized by a touch panel or the like having a display function and an input function. The display device 304 and the input device 305 may not be provided in the QKD device 1. In this case, for example, the display function and input function of an external terminal connected to the QKD device 1 are used.
[0173] The quantum communication IF 306 is an interface for connecting to a QKD link through which photons are transmitted. The classical communication IF 307 is an interface for connecting to a transmission path through which control signals are transmitted between the opposing QKD device 1 and a transmission path for communication with the key management device 2-2.
[0174] 23 is a diagram showing an example of the hardware configuration of the key management device 2-2 according to the first to third embodiments. The key management device 2-2 includes a control device 401, a main storage device 402, an auxiliary storage device 403, a display device 404, an input device 405, and a communication IF 406.
[0175] The control device 401 , the main memory device 402 , the auxiliary memory device 403 , the display device 404 , the input device 405 and the communication IF 406 are connected via a bus 410 .
[0176] The control device 401 executes a program read from the auxiliary storage device 403 to the main storage device 402. The main storage device 402 is a memory such as a ROM and a RAM. The auxiliary storage device 403 is a HDD, a memory card, or the like.
[0177] The display device 404 displays the status of the key management device 2-2, etc. The input device 405 accepts input from a user. The display device 404 and the input device 405 may be realized by a touch panel or the like having a display function and an input function. The display device 404 and the input device 405 may not necessarily be provided in the key management device 2-2. In this case, for example, the display function and the input function of an external terminal connected to the key management device 2-2 are used.
[0178] The communication IF 406 is an interface for connecting to a transmission line.
[0179] The programs executed by the QKD device 1 and key management device 2-2 of the first to third embodiments are provided as computer program products stored in installable or executable format files on computer-readable storage media such as CD-ROMs, memory cards, CD-Rs, and DVDs (Digital Versatile Discs).
[0180] In addition, the programs executed by the QKD device 1 and key management device 2-2 of the first to third embodiments may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network.
[0181] Furthermore, the programs executed by the QKD device 1 and key management device 2-2 of the first to third embodiments may be configured to be provided via a network such as the Internet without being downloaded.
[0182] Furthermore, the programs executed by the QKD device 1 and key management device 2-2 of the first to third embodiments may be configured to be provided in advance by being stored in a ROM or the like.
[0183] The programs executed by the QKD device 1 and key management device 2-2 of the first to third embodiments have a modular configuration that includes functions that can be realized by the programs, among the functional configurations of the QKD device 1 and key management device 2-2 of the first to third embodiments. The functions realized by the programs are loaded into the main memory device 402 by the control device 401 reading and executing the programs from a storage medium such as the auxiliary storage device 403. In other words, the functions realized by the programs are generated on the main memory device 402.
[0184] It should be noted that some or all of the functions of the QKD device 1 and key management device 2-2 in the first to third embodiments may be realized by hardware such as an IC (Integrated Circuit). The IC is, for example, a processor that executes dedicated processing.
[0185] Furthermore, when each function is realized using a plurality of processors, each processor may realize one of the functions, or may realize two or more of the functions.
[0186] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims.
[0187] (Addendum) The above-described embodiments can be summarized as the following technical proposals.
[0188] Technical proposal 1 An information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, a first processing unit that, after determining a transfer destination of a received packet, controls execution of decryption of the encrypted second encryption key included in the packet; An information processing device comprising: Technical proposal 2 a second processing unit that performs a transmission process of transmitting a packet including the encrypted second encryption key to another information processing device via a network IF (Interface); The information processing device according to Technical Solution 1 further comprises: Technical proposal 3 When the transfer destination is another information processing device, the first processing unit identifies a network IF to be used for transmitting the packet from destination information included in the packet, identifies the first encryption key to be used for encryption from the network IF to be used for transmitting the packet, and controls execution of encryption of the second encryption key using the identified first encryption key before transmission processing by the second processing unit. An information processing device according to Technical Proposal 2. Technical proposal 4 the first processing unit, after determining a transfer destination of the received packet, identifies a network IF used to receive the packet, identifies a first decryption key to be used for decryption from the network IF used to receive the packet, controls execution of decryption of the second encryption key using the identified first decryption key, and then controls execution of encryption of the second encryption key using the first encryption key before transmission processing by the second processing unit; An information processing device according to Technical Proposal 3. Technical proposal 5 when the transfer destination is another information processing device, the first processing unit identifies a network IF used to transmit the packet from destination information included in the packet, identifies the first encryption key used for encryption from the network IF used to transmit the packet, and controls execution of encryption of the second encryption key using the identified first encryption key; Next, a network IF used to receive the packet is identified, a first decryption key to be used for decryption is identified from the network IF used to receive the packet, and execution control of decryption of the second encryption key using the identified first decryption key is performed before the transmission process by the second processing unit. An information processing device according to Technical Proposal 2. Technical proposal 6 the first processing unit, when the transfer destination is another information processing device, identifies a network IF used to receive the packet, and identifies a first decryption key used for decryption from the network IF used to receive the packet; Identifying a network IF used to transmit the packet from destination information included in the packet, and identifying the first encryption key used for encryption from the network IF used to transmit the packet; generating a third encryption key from the identified first decryption key and the identified first encryption key; a control of simultaneous execution of decryption and encryption of the second encryption key by the third encryption key is performed before the transmission process by the second processing unit; An information processing device according to Technical Proposal 2. Technical proposal 7 When the transfer destination is another information processing device, the first processing unit performs the decryption process and the encryption process using a packet transfer hook function in iptables or nftables. An information processing device according to any one of technical proposals 3 to 6. Technical proposal 8 When the transfer destination is the device itself, the first processing unit controls execution of decryption of the encrypted second encryption key included in the packet, and then performs input processing to store the decrypted second encryption key in a storage device. An information processing device according to any one of technical proposals 1 to 7. Technical proposal 9 The first processing unit performs the input processing using an input hook function in iptables or nftables. An information processing device according to Technical Proposal 8. Technical proposal 10 further comprising a random number generator for generating a random number representing the second encryption key; when transmitting the second encryption key generated by the random number generator to another information processing device, the first processing unit performs an output process for controlling execution of encryption of the second encryption key generated by the random number generator after determining a destination of a packet including the second encryption key generated by the random number generator and before a transmission process by the second processing unit. An information processing device according to any one of technical proposals 2 to 9. Technical proposal 11 The first processing unit performs the output processing using an output hook function in iptables or nftables. An information processing device according to Technical Proposal 10. Technical proposal 12 The first processing unit determines packets to be decrypted or encrypted based on a filter setting by iptables or nftables. An information processing device according to any one of technical proposals 1 to 11. Technical proposal 13 An information processing device according to any one of technical proposals 1 to 12; a QKD device that provides the first encryption key to the information processing device; A quantum cryptography communication system comprising: Technical proposal 14 Another information processing device that receives a packet transmitted from the information processing device according to any one of technical proposals 1 to 12; The quantum cryptography communication system according to Technical Proposal 13 further comprises: Technical proposal 15 1. An information processing method of an information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, After determining a forwarding destination of the received packet, the execution of decryption of the encrypted second encryption key included in the packet is controlled. Information processing methods. Technical proposal 16 An information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, determining a transfer destination of the received packet, and then controlling execution of decryption of the encrypted second encryption key included in the packet; program. [Explanation of symbols]
[0189] 1 QKD device 2 Key management device (KM) 21 Key Management Department 22 Memory section 23 Transfer processing section 24 Network IF processing unit 25 Decryption processing unit 26 Encryption processing unit 27 First Processing Section 28 Second Processing Section 100 QKD Networks 271 Input packet route determination unit 272 Input packet processing unit 273 Forwarding packet processing section 274 Output packet route determination unit 275 Output packet processing unit 281 Network IF Processing Unit 282 Encryption / Decryption Processing Unit 301 Control device 302 Main storage 303 Auxiliary storage device 304 Display device 305 Input Device 306 Quantum Communication Interface 307 Classical Communication IF 310 Bus 401 Control device 402 Main storage 403 Auxiliary storage 404 Display device 405 Input Device 406 Communication Interface 410 Bus
Claims
1. An information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, a first processing unit that, after determining a transfer destination of a received packet, controls execution of decryption of the encrypted second encryption key included in the packet; An information processing device comprising:
2. a second processing unit that performs a transmission process of transmitting a packet including the encrypted second encryption key to another information processing device via a network IF (Interface); The information processing device according to claim 1 , further comprising:
3. When the transfer destination is another information processing device, the first processing unit identifies a network IF to be used for transmitting the packet from destination information included in the packet, identifies the first encryption key to be used for encryption from the network IF to be used for transmitting the packet, and controls execution of encryption of the second encryption key using the identified first encryption key before transmission processing by the second processing unit. The information processing device according to claim 2 .
4. the first processing unit, after determining a transfer destination of the received packet, identifies a network IF used to receive the packet, identifies a first decryption key to be used for decryption from the network IF used to receive the packet, controls execution of decryption of the second encryption key using the identified first decryption key, and then controls execution of encryption of the second encryption key using the first encryption key before a transmission process by the second processing unit. The information processing device according to claim 3 .
5. the first processing unit, when the transfer destination is another information processing device, identifies a network IF to be used for transmitting the packet from destination information included in the packet, identifies the first encryption key to be used for encryption from the network IF to be used for transmitting the packet, and controls execution of encryption of the second encryption key using the identified first encryption key; Next, a network interface used for receiving the packet is identified, a first decryption key to be used for decryption is identified from the network interface used for receiving the packet, and execution control of decryption of the second encryption key using the identified first decryption key is performed before a transmission process by the second processing unit. The information processing device according to claim 2 .
6. the first processing unit, when the transfer destination is another information processing device, identifies a network IF used to receive the packet, and identifies a first decryption key used for decryption from the network IF used to receive the packet; Identifying a network interface used to transmit the packet from destination information included in the packet, and identifying the first encryption key used for encryption from the network interface used to transmit the packet; generating a third encryption key from the identified first decryption key and the identified first encryption key; a control of simultaneous execution of decryption and encryption of the second encryption key by the third encryption key is performed before the transmission process by the second processing unit; The information processing device according to claim 2 .
7. When the transfer destination is another information processing device, the first processing unit performs the decryption process and the encryption process using a packet transfer hook function in iptables or nftables. The information processing device according to claim 3 .
8. When the transfer destination is the device itself, the first processing unit controls execution of decryption of the encrypted second encryption key included in the packet, and then performs input processing of storing the decrypted second encryption key in a storage device. The information processing device according to claim 1 .
9. The first processing unit performs the input processing using an input hook function in iptables or nftables. The information processing device according to claim 8 .
10. further comprising a random number generator for generating a random number representing the second encryption key; when transmitting the second encryption key generated by the random number generator to another information processing device, the first processing unit performs an output process for controlling execution of encryption of the second encryption key generated by the random number generator after determining a destination of a packet including the second encryption key generated by the random number generator and before a transmission process by the second processing unit. The information processing device according to claim 2 .
11. The first processing unit performs the output process using an output hook function in iptables or nftables. The information processing device according to claim 10.
12. The first processing unit determines packets to be subjected to decryption or encryption based on a filter setting using iptables or nftables. The information processing device according to claim 1 .
13. An information processing device according to any one of claims 1 to 6; A QKD device that provides the first encryption key to the information processing device; A quantum cryptography communication system comprising:
14. Another information processing device that receives a packet transmitted from the information processing device according to any one of claims 1 to 6; The quantum cryptography communication system according to claim 13, further comprising:
15. 1. An information processing method of an information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, the method comprising: After determining a transfer destination of the received packet, the execution control is performed to decrypt the encrypted second encryption key included in the packet. Information processing methods.
16. An information processing device that relays a second encryption key encrypted with a first encryption key shared between opposing QKD devices included in a QKD (Quantum Key Distribution) network, determining a transfer destination of the received packet, and then controlling execution of decryption of the encrypted second encryption key included in the packet; program.
Citation Information
Patent Citations
Communication apparatus, communication method, program and communication system
JP2016171530A
Quantum key distribution method and device, and storage medium
US20210044432A1
Method and apparatus for routing data traffic in a cryptographically-protected network
US7392378B1
Method of operation of a trusted node software in a quantum key distribution system
WO2020226981A1
Key exchange system, QKD device, base device, method and program
WO2023218574A1