COMMUNICATION CONTROL DEVICE, COMMUNICATION ... SYSTEM, METHOD, AND PROGRAM

Abstract

To provide a communication control device, a communication device, a communication system, a method, and a program, capable of implement low-delay communication when a cryptographic communication method in which a key is sequentially switched is used.SOLUTION: A communication control device according to an embodiment includes an acquisition unit, a first processing unit, a request unit, and a first memory unit. The acquisition unit acquires data transmitted from a first communication device to a second communication device or data transmitted from the second communication device to the first communication device, via a network; the first processing unit performs an encryption process or a decryption process on the acquired data by using key data in a case where the data belongs to a flow to be encrypted or decrypted; a request unit requests transfer of the key data for each flow via an internal bus of the first communication device; and a first memory unit stores the key data transferred in response to the request.SELECTED DRAWING: Figure 3

Description

[Technical Field]

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

[0002] BACKGROUND ART In recent years, communication devices have become known that transmit and receive communication data using quantum cryptography (hereinafter referred to as quantum cryptography communication), which is an encryption technique based on the theory of quantum mechanics.

[0003] In quantum cryptography communication, a key (data) is shared between a communication device that transmits communication data and a communication device that receives the communication data, for example, by quantum key distribution, and the communication data is encrypted and decrypted using the key.

[0004] Incidentally, in order to improve the security of communication data, an encryption communication method called One Time Pad (OTP) is sometimes used, which does not reuse the key (data) used for encryption and decryption.

[0005] In this case, in order to achieve low-latency communication, a mechanism for smoothly switching keys is required in a communication control device such as a network interface provided in the communication device. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent No. 5465335 Summary of the Invention [Problem to be solved by the invention]

[0007] Therefore, the problem that the present invention aims to solve is to provide a communication control device, communication device, communication system, method, and program that can achieve low-latency communication when a cryptographic communication method that switches keys sequentially is used. [Means for solving the problem]

[0008] According to an embodiment, a communication control device is provided for a first communication device. The communication control device includes an acquisition unit, a first processing unit, a request unit, and a first storage unit. The acquisition unit acquires data transmitted from the first communication device to a second communication device or data transmitted from the second communication device to the first communication device via a network. If the acquired data belongs to a flow to be encrypted or decrypted, the first processing unit performs encryption or decryption on the data using key data. The request unit requests transfer of key data for each flow via an internal bus of the first communication device. The first storage unit stores the key data transferred in response to the request. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an overview of a communication system according to a first embodiment. [Figure 2] FIG. 1 is a diagram showing an example of a hardware configuration of an encryption communication device. [Figure 3] FIG. 2 is a block diagram showing an example of the functional configuration of the encryption communication device. [Figure 4] 10 is a flowchart showing an example of a processing procedure for a transmission side setting process. [Figure 5] FIG. 4 is a diagram showing an example of the data structure of first key management data. [Figure 6] FIG. 10 is a diagram showing an example of the data structure of second key management data. [Figure 7] FIG. 2 is a diagram showing an example of a frame format. [Figure 8] FIG. 10 is a diagram showing an example of a packet format. [Figure 9] FIG. 4 is a diagram for explaining a buffer area of ​​a first key storage unit. [Figure 10] FIG. 10 is a diagram showing an example of ring buffer management. [Figure 11] 10 is a flowchart showing an example of a processing procedure for a receiving side setting process. [Figure 12] FIG. 10 is a diagram showing an example of the settings of a flow identification unit. [Figure 13] 10 is a flowchart showing an example of a processing procedure for a key data transfer process. [Figure 14] FIG. 1 is a diagram for explaining an overview of key data transfer. [Figure 15] FIG. 10 is a diagram showing an example of a descriptor entry in a key transfer descriptor ring. [Figure 16] 10 is a flowchart showing an example of a processing procedure for a frame transmission process. [Figure 17] FIG. 2 is a diagram for explaining an overview of transfer of a transmission frame. [Figure 18] FIG. 10 is a diagram showing an example of a descriptor entry in a transmit frame descriptor ring. [Figure 19] FIG. 10 is a diagram showing an example of auxiliary information set in a transmission frame. [Figure 20] FIG. 2 is a diagram showing an example of the internal configuration of an encryption processing unit. [Figure 21] 10 is a flowchart showing an example of a processing procedure for a frame reception process. [Figure 22] FIG. 2 is a diagram showing an example of the internal configuration of a decoding processing unit. [Figure 23] FIG. 2 is a diagram for explaining an overview of transfer of a received frame. [Figure 24] FIG. 10 is a diagram showing an example of a descriptor entry in a receive frame descriptor ring. [Figure 25] FIG. 2 is a diagram showing an example of the internal configuration of an encryption / decryption processing unit. [Figure 26] FIG. 10 is a diagram for explaining a first modified example of the present embodiment. [Figure 27] FIG. 10 is a diagram for explaining a second modified example of the present embodiment. [Figure 28] 10 is a flowchart showing an example of a processing procedure of an encrypted communication device according to a second modified example of the present embodiment. [Figure 29] FIG. 10 is a diagram for explaining a third modified example of the present embodiment. [Figure 30] FIG. 10 is a block diagram showing an example of the functional configuration of an encryption communication device according to a second embodiment. [Figure 31] 10 is a flowchart showing an example of a processing procedure for a key data transfer process. [Figure 32] FIG. 4 is a diagram showing an example of the data structure of first key management data. [Figure 33] FIG. 10 is a diagram showing an example of an interface of a key data accepting unit. [Figure 34] FIG. 10 is a diagram showing an example of a descriptor entry in a key transfer descriptor ring. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, each embodiment will be described with reference to the drawings. (First embodiment) First, a first embodiment will be described. A communication device according to this embodiment is configured to transmit and receive communication data by quantum cryptography communication (communication using quantum cryptography). In quantum cryptography communication, a communication device that transmits communication data (hereinafter referred to as a sending-side cryptographic communication device) and a communication device that receives the communication data (hereinafter referred to as a receiving-side cryptographic communication device) share key data (a common key) used for encryption and decryption of the communication data. This sharing of key data is achieved by quantum key distribution (QKD).

[0011] Hereinafter, with reference to FIG. 1, an outline of a communication system that performs quantum cryptography communication by sharing key data through quantum key distribution will be described.

[0012] As shown in FIG. 1, the communication system 1 includes a transmitting-side QKD device 10a, a receiving-side QKD device 10b, a transmitting-side encrypted communication device 20a, and a receiving-side encrypted communication device 20b.

[0013] The transmitting side QKD device 10a and the receiving side QKD device 10b operate to share key data by quantum key distribution via a quantum communication channel 2 and a classical communication channel 3.

[0014] Transmitting side QKD device 10a includes a key generation unit 11a, a key transmission unit 12a, a communication unit 13a, a key distillation unit 14a, and a key provision unit 15a.

[0015] The key generating unit 11a generates key data from random numbers. The key data used in this embodiment is, for example, a common key defined in a common key cryptosystem.

[0016] Key transmitter 12a transmits the key data generated by key generator 11a continuously as single photons to receiver QKD device 10b via quantum communication channel 2 (optical fiber).

[0017] The communication unit 13a communicates with the receiving QKD device 10b for key distillation via a classical communication channel 3 (for example, a network such as Ethernet (registered trademark)).

[0018] The key distillation unit 14a performs key distillation to eliminate bit strings that may be susceptible to eavesdropping from the key data transmitted via the quantum communication channel 2, based on communication with the receiving QKD device 10b performed by the communication unit 13a (e.g., exchange of control data, etc.).

[0019] The key providing unit 15a provides (transmits) the key data obtained by the key distillation performed by the key distillation unit 14a to the encryption communication device 20a on the transmitting side via a LAN (Local Area Network) or an internal bus.

[0020] Receiving side QKD device 10b includes a key receiving unit 11b, a communication unit 12b, a key distillation unit 13b, and a key providing unit 14b.

[0021] The key receiving unit 11b receives the key data (single photon) transmitted from the transmitting QKD device 10a via the quantum communication channel 2.

[0022] The communication unit 12b communicates with the transmitting QKD device 10a via the classical channel 3 for key distillation.

[0023] The key distillation unit 13b performs key distillation to eliminate bit strings that may be susceptible to eavesdropping from the key data received via the quantum communication channel 2, based on communication with the transmitting QKD device 10a performed by the communication unit 12b.

[0024] The key providing unit 14b provides (transmits) the key data obtained by the key distillation performed by the key distillation unit 13b to the receiving-side encryption communication device 20b via a LAN, an internal bus, or the like.

[0025] According to the above-described transmitting side QKD device 10a and receiving side QKD device 10b, it becomes possible for the transmitting side encryption communication device 20a and the receiving side encryption communication device 20b to safely obtain the same key data (common key).

[0026] It is assumed that the security of communication between the transmitting QKD device 10a and the transmitting encryption communication device 20a and communication between the receiving QKD device 10b and the receiving encryption communication device 20b is guaranteed (i.e., there is no possibility of eavesdropping on the key data provided from the transmitting QKD device 10a to the transmitting encryption communication device 20a and the key data provided from the receiving QKD device 10b to the receiving encryption communication device 20b).

[0027] The transmitting-side encryption communication device 20a includes a communication application unit 21a, an encryption processing unit 22a, and a communication unit 23a. The communication application unit 21a outputs communication data. The encryption processing unit 22a encrypts the communication data output from the communication application unit 21a using key data provided by the transmitting-side QKD device 10a. The encryption processing unit 22a obtains encrypted data obtained by, for example, performing an exclusive OR between the communication data and the key data. The communication unit 23a transmits the encrypted data obtained in the encryption processing unit 22a to the receiving-side encryption communication device 20b via the classical communication channel 4.

[0028] The receiving-side encryption communication device 20b includes a communication unit 21b, a decryption processing unit 22b, and a communication application unit 23b. The communication unit 21b receives encrypted data transmitted from the transmitting-side encryption communication device 20a. The decryption processing unit 22b decrypts the encrypted data received by the communication unit 21b using key data provided by the receiving-side QKD device 10b. The decryption processing unit 22b acquires decrypted data obtained by, for example, performing an exclusive OR between the encrypted data and the key data. The communication application unit 23b executes processing using the decrypted data (i.e., communication data) acquired by the decryption processing unit 22b.

[0029] According to the above-described communication system 1, communication by common key encryption using common key data provided by the transmitting-side QKD device 10a and the receiving-side QKD device 10b is possible between the transmitting-side encryption communication device 20a and the receiving-side encryption communication device 20b. Specifically, in the communication system 1, communication data is encrypted and decrypted using key data shared by quantum key distribution, thereby realizing communication that can prevent eavesdropping by a third party.

[0030] The encryption communication method used in the above-described communication system 1 is, for example, one-time pad (OTP). One-time pad is a method for performing encryption and decryption using key data of the same length (size) as the communication data, and does not reuse key data once used. This can improve the security of sending and receiving communication data using the classical communication channel 4.

[0031] The encryption communication device according to this embodiment will be described in detail below. Fig. 2 shows an example of the hardware configuration of an encryption communication device. As shown in Fig. 2, the encryption communication device 20 includes a CPU (central processing unit) 101, a main memory (primary storage device) 102, a storage (auxiliary storage device) 103, and a network interface (communication control device) 104. Note that in this embodiment, the encryption communication device 20 may be either the encryption communication device 20a on the sending side or the encryption communication device 20b on the receiving side described above.

[0032] The CPU 11 and the main memory 102 are connected by a memory bus 105. The CPU 102, the storage 103, and the network interface 104 are connected by an expansion bus 106. The expansion bus 106 connects the CPU 101 to peripheral devices and includes, for example, a bus (PCIe bus) conforming to the PCIe (Peripheral Component Interconnect Express) standard. Note that while FIG. 2 assumes that the memory bus 105 and the expansion bus 106 are different buses, the main memory 102 may be connected to the CPU 101 via the expansion bus 106. The memory bus 105 and the expansion bus 106 may be collectively referred to as an internal bus.

[0033] The CPU 101 includes a built-in memory controller (not shown), and executes a program while reading the program loaded onto the main memory 102. The main memory 102 is configured by, for example, a DRAM (Dynamic Random Access Memory).

[0034] The CPU 101 also controls the storage 103 and the network interface 104 via the expansion bus 106. Specifically, the CPU 101 writes and reads data to and from the storage 103. The CPU 101 also transmits and receives communication data (for example, frames) using the network interface 104.

[0035] In this embodiment, the CPU 101 and the main memory 102 are referred to as a host (host computer) for convenience.

[0036] The storage 103 is configured, for example, by an SSD (Solid State Drive), and the network interface 104 is configured, for example, by an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) so as to send and receive Ethernet frames.

[0037] Although not shown in FIG. 2, the encryption communication device 20 may further include a DRAM or SRAM (Static Random Access Memory) for storing data in the network interface 104.

[0038] Note that the data configuration unit (PDU: Protocol Data Unit) in communication between the encryption communication devices 20 (between the sending encryption communication device 20a and the receiving encryption communication device 20b) is called a frame (layer 2), a packet (layers 3 and 4), a segment (layer 4 TCP, etc.), or a datagram (layer 4 UDP, etc.) depending on the communication layer or communication protocol. In this embodiment, the description will be mainly based on the assumption that the data configuration unit is a frame.

[0039] Fig. 3 is a block diagram showing an example of the functional configuration of the encryption communication device 20. As shown in Fig. 3, the encryption communication device 20 includes a communication unit 201, a priority identification unit 202, a flow identification unit 203, a reception control unit 204, a decryption determination unit 205 (first decryption determination unit), a decryption processing unit 206 (first decryption processing unit), a received frame storage unit 207, a frame transfer unit 208, an encryption determination unit 209 (first encryption determination unit), an encryption processing unit 210 (first encryption processing unit), a transmission frame storage unit 211, a transmission control unit 212, a first key storage unit 213, a key data management unit 214, a key data transfer unit 215, a key data reception unit 216, and a priority arbitration unit 217. Furthermore, the encryption communication device 20 includes a communication application unit 218, a communication control unit 219, a key management application unit 220, a key acquisition unit 221, a key transfer control unit 222, and a second key storage unit 223.

[0040] Some or all of the above-mentioned units 201 to 223 may be realized by the computer of the encryption communication device 20 executing a predetermined program (i.e., software), or may be realized by hardware, or may be realized by a combination of software and hardware.

[0041] In this embodiment, the units 201 to 217 are functional units realized by the network interface 104 connected to the host (CPU 101 and main memory 102) via an internal bus. The units 218 to 223 are functional units realized by the host. Note that some of the units 218 to 223 may be realized by the CPU 101 alone, or by the main memory 102 alone.

[0042] 3 is connected to the QKD device 10 (the transmitting QKD device 10a or the receiving QKD device 10b), and is configured to be able to operate as the transmitting-side encrypted communication device 20a shown in FIG. 1, and also to be able to operate as the receiving-side encrypted communication device 20b. In other words, the encrypted communication device 20 includes a functional unit for realizing the functions of the transmitting-side encrypted communication device 20a, and a functional unit for realizing the functions of the receiving-side encrypted communication device 20b. As an example, the units 201 to 208 realized by the network interface 104 correspond to the functions of the receiving-side encrypted communication device 20b (i.e., the receiving-side network interface). Furthermore, the units 201 and 208 to 212 realized by the network interface 104 correspond to the functions of the transmitting-side encrypted communication device 20a (i.e., the transmitting-side network interface).

[0043] The communication application unit 21a included in the transmitting-side encryption communication device 20a and the communication application unit 23b included in the receiving-side encryption communication device 20b shown in Fig. 1 correspond to the communication application unit 218 shown in Fig. 3. The encryption processing unit 22a included in the transmitting-side encryption communication device 20a shown in Fig. 1 corresponds to the encryption processing unit 210 shown in Fig. 3. The decryption processing unit 22b included in the receiving-side encryption communication device 20b shown in Fig. 1 corresponds to the decryption processing unit 206 shown in Fig. 3. The communication unit 23a included in the transmitting-side encryption communication device 20a and the communication unit 21b included in the receiving-side encryption communication device 20b shown in Fig. 1 correspond to the communication unit 201 shown in Fig. 3.

[0044] Below is an overview of the units 201 to 223 included in the above-mentioned encryption communication device 20. In the following explanation, when the encryption communication device 20 operates as the encryption communication device 20a on the sending side, a frame transmitted from the encryption communication device 20a on the sending side to the encryption communication device 20b on the receiving side is referred to as a transmission frame, and when the encryption communication device 20 operates as the encryption communication device 20b on the receiving side, a frame transmitted from the encryption communication device 20a on the sending side to the encryption communication device 20b on the receiving side (i.e., a frame received by the encryption communication device 20b on the receiving side) is referred to as a reception frame.

[0045] The communication unit 201 transmits and receives frames via a network (classical communication channel 4). The communication unit 201 executes processing for communication using a protocol such as Ethernet. Specifically, the communication unit 201 executes processing of the data link layer and physical layer in the OSI reference model, and realizes functions called MAC (Media Access Controller) and PHY. Note that the network interface 104 may be provided with multiple communication units 201. In this embodiment, the communication unit 201 corresponds to an acquisition unit that acquires data (received frames) transmitted from another encryption communication device 20 (second communication device) to the encryption communication device 20 (first communication device).

[0046] The priority identification unit 202 determines the priority of the received frame. The priority determined by the priority identification unit 202 is set as attached information of the received frame.

[0047] The flow identification unit 203 uses a flow identifier (flow identification information) (to be described later) and (the data of) the received frame to identify the flow to which the received frame belongs.

[0048] The reception control unit 204 performs reception processing in accordance with the TSN (Time-Sensitive Networking) standard defined in IEEE 802.1. For example, the reception control unit 204 performs processing such as limiting the input of a specific flow, or removing duplicate frames when duplicate frames are received in order to improve the stability of frame transmission and reception.

[0049] The decryption determination unit 205 determines whether or not the received frame is a target for decryption processing based on the flow identifier and (information about) the encryption method corresponding to the flow identifier.

[0050] The decryption processing unit 206 reads key data from the first key storage unit 213 (described later) and decrypts the received frame using the key data. The decryption processing unit 206 executes decryption processing on the received frame (encrypted data) in accordance with the encryption method corresponding to the flow identifier, thereby obtaining the decrypted received frame (plaintext data).

[0051] The received frame storage unit 207 stores the received frame. The received frame storage unit 207 has queues (FIFO: First In First Out) prepared for each priority.

[0052] The frame transfer unit 208 transfers data (plaintext data, described later) of frames (received frames and transmitted frames) between the host (main memory 102) and the network interface 104 by DMA (Direct Memory Access) without processing by the CPU 102. Note that the transfer of frames by the frame transfer unit 208 is controlled based on the priority of the frame (priority assigned to the flow to which the frame belongs). In this embodiment, the frame transfer unit 208 corresponds to an acquisition unit that acquires data (transmission frames) to be transmitted from an encryption communication device 20 (first communication device) to another encryption communication device 20 (second communication device) via a network.

[0053] The encryption determination unit 209 determines whether or not the transmission frame is to be encrypted based on the flow identifier and (information about) the encryption method corresponding to the flow identifier.

[0054] The encryption processing unit 210 reads out key data from the first key storage unit 213 and encrypts the transmission frame using the key data. The encryption processing unit 210 performs encryption processing on the transmission frame (plain text data) in accordance with the encryption method corresponding to the flow identifier, thereby obtaining the encrypted transmission frame (encrypted data).

[0055] The transmission frame storage unit 211 stores transmission frames. The transmission frame storage unit 211 has queues (FIFO) prepared for each priority.

[0056] The transmission control unit 212 controls the transmission order of transmission frames by performing transmission processing in accordance with the above-mentioned TSN standard. Specifically, the transmission control unit 212 performs processing such as Enhancements for Scheduled Traffic (EST), which controls frame transmission by opening and closing a gate based on priority, Frame Preemption, which interrupts the transmission of low-priority frames and transmits high-priority frames, and Frame Replication, which duplicates and transmits frames.

[0057] The first key storage unit 213 stores key data transferred from the host for each flow. The key data stored in the first key storage unit 213 is provided to the decryption processing unit 206 in response to a decryption request, and is provided to the encryption processing unit 210 in response to an encryption request. The key data stored in the first key storage unit 213 is read out sequentially according to the length of the frame (data) to be decrypted and encrypted, and is used in the decryption and encryption processes.

[0058] Key data management unit 214 manages the key data stored in first key storage unit 213. Furthermore, key data management unit 214 requests key transfer control unit 222 to transfer key data for each flow, based on the amount of key data stored in first key storage unit 213 for each flow.

[0059] The key data transfer unit 215 executes a process of transferring key data from the host (second key storage unit 223) to the network interface 104 (first key storage unit 213).

[0060] The key data receiving unit 216 receives the key data via the key data transferring unit 215 and writes the key data into the first key storage unit 213 .

[0061] The priority arbitration unit 217 arbitrates between the transfer of frames by the frame transfer unit 208 and the transfer of key data by the key data transfer unit 215 based on priority.

[0062] The communication application unit 218 is realized by an application (program) running on the encryption communication device 20, and transmits and receives communication data via the communication control unit 219. When the encryption communication device 20 operates as the encryption communication device 20a on the sending side, the communication application unit 218 operates to generate communication data to be transmitted to another encryption communication device 20 (i.e., the encryption communication device 20b on the receiving side). When the encryption communication device 20 operates as the encryption communication device 20b on the receiving side, the communication application unit 218 operates to execute processing on communication data received from another encryption communication device 20 (i.e., the encryption communication device 20a on the sending side) (i.e., to consume the communication data). Furthermore, the communication application unit 218 sets key data used in communication (encryption and decryption of frames) and a flow identifier (information for identifying a flow) via the communication control unit 219 and the key management application unit 220. Note that there may be multiple communication application units 218 depending on the applications running on the encryption communication device 20.

[0063] The communication control unit 219 controls communication using the network interface 104 in response to instructions from the communication application unit 218. The communication control unit 219 is realized by the functions of a protocol stack for communication and the driver of the network interface 104.

[0064] Key management application unit 220 manages key data used for communication in response to instructions from communication application unit 218. Specifically, key management application unit 220 instructs key acquisition unit 221 to acquire key data and store it in second key storage unit 223. Key management application unit 220 also instructs key transfer control unit 222 to transfer the key data.

[0065] The key acquisition unit 221 acquires key data, for example, from the QKD device 10 (key providing unit) in response to an instruction from the key management application unit 220. The key acquisition unit 221 also writes (stores) the acquired key data in the second key storage unit 223.

[0066] In response to an instruction from the key management application unit 220, the key transfer control unit 222 performs control for transferring the key data stored in the second key storage unit 223 to the network interface 104.

[0067] The second key storage unit 223 is configured to store key data. The second key storage unit 223 is realized by the main memory 102. That is, an area for the second key storage unit 223 is secured within the main memory 102.

[0068] Next, we will explain the operation of the encryption communication device 20 according to this embodiment. When an encryption communication method that sequentially switches key data, such as a one-time pad, is used in quantum cryptography communication, the encryption communication device 20 according to this embodiment has a mechanism for smoothly transferring key data provided by the QKD device 10 from the host (CPU 101 and main memory 102) side to the network interface 104 side in advance in order to achieve low-latency communication.

[0069] In this embodiment, in order to achieve the smooth transfer of the key data described above, the following processes are executed: a setting process for operating as the sending-side encrypted communication device 20a (hereinafter referred to as sending-side setting process), a setting process for operating as the receiving-side encrypted communication device 20b (hereinafter referred to as receiving-side setting process), a process for transferring key data provided by the QKD device 10 (key provider) from the host to the network interface 104 (hereinafter referred to as key data transfer process), a process for operating as the sending-side encrypted communication device 20a to transmit frames (hereinafter referred to as frame transmission process), and a process for operating as the receiving-side encrypted communication device 20b to receive frames (hereinafter referred to as frame reception process). Each of these processes will be described below.

[0070] An example of the processing procedure of the above-mentioned transmission side setting processing will be described with reference to the flowchart of Fig. 4. In the description of Fig. 4, the encryption communication device 20 refers to the encryption communication device 20a on the transmission side, and the other encryption communication device 20 refers to the encryption communication device 20b on the reception side.

[0071] First, the communication application unit 218 included in the encryption communication device 20 is realized by the operation of an application on the encryption communication device 20 that starts communication with another encryption communication device 20, and operates to generate communication data to be transmitted to the other encryption communication device 20. The communication application unit 218 sets up the communication control unit 219 to transmit the communication data thus generated to the other encryption communication device 20 (step S1).

[0072] In step S1, the priority of communication data generated by the communication application unit 218 (i.e., communication performed by the communication application unit 218) and an identifier (flow identifier) ​​for identifying the flow to which the communication data (frames for transmitting) belongs are set. Note that a flow corresponds to a series of communication sequences, and frames that share common attributes such as a MAC address, VLAN ID, IP address, port number, and protocol number are treated as belonging to the same flow. The flow identifier can be said to be information for identifying an application or a communication flow used within an application.

[0073] Next, communication application unit 218 instructs key management application unit 220 to acquire key data (step S2).

[0074] Here, the key data is acquired using a key acquisition interface such as that specified in ETSI GS QKD 004. In this case, the key management application unit 220 acquires the above-mentioned key data and a QKD key identifier for identifying the key data by specifying, in the application that initiates communication, the identifier (SAE ID) of the application with which the communication is to be performed (step S3). Note that the key data and QKD key identifier are acquired via the key acquisition unit 221.

[0075] The key data acquired in step S3 is stored in second key storage unit 223 (step S4). The key data stored in second key storage unit 223 in step S4 is managed by key management application unit 220 for each flow.

[0076] Here, FIG. 5 shows an example of the data structure of data for managing the key data stored in second key storage unit 223 (hereinafter referred to as first key management data).

[0077] As shown in FIG. 5, the first key management data stores, for example, a priority, a QKD key index, a QKD key identifier, an address, a length, and a transferred data size in association with the above-mentioned flow identifier.

[0078] The priority corresponds to the priority set in step S1 described above. The QKD key index corresponds to management information such as a number assigned to key data for sequential use. The QKD key identifier is information for identifying key data as described above, and is, for example, KeyID in ETSI GS QKD 004. The address indicates the position (address) of the key data stored in the second key storage unit 223. The length indicates the length (data size) of the key data stored in the second key storage unit 223. The transferred data size indicates the size (position, offset) of the key data stored in the second key storage unit 223 that has already been instructed to be transferred from the CPU 101 and main memory 102 to the network interface 104.

[0079] Returning to FIG. 4 again, the QKD key identifier acquired in step S3 is notified to the other encryption communication device 20 (that is, the encryption communication device 20 of the communication partner) (step S5).

[0080] Next, the key management application unit 220 sets the key data management unit 214 via the key transfer control unit 222 (step S6). In step S6, for example, data for managing the decryption processing unit 206, the encryption processing unit 210, and the first key storage unit 213 (hereinafter referred to as second key management data) is set.

[0081] Fig. 6 shows an example of the data structure of the second key management data. As shown in Fig. 6, in the second key management data, for example, the encryption method, write position, read position, circulation count, and buffer size are set in association with the above-mentioned flow identifier.

[0082] As the encryption method, for example, the L2 encryption / OTP method can be specified. This L2 encryption / OTP method indicates that L2 encryption is performed using the OTP method. Here, FIG. 7 shows an example of the frame format in layer 2 described above. FIG. 7 shows a plaintext frame containing plaintext data and a frame (encrypted frame) that has been L2 encrypted as encryption at layer 2. Note that in L2 encryption, headers of layers 3 and above are simply treated as plaintext data. As shown in FIG. 7, when a plaintext frame is encrypted, encryption information (encryption header) is added to the encrypted frame along with encrypted data obtained by encrypting the plaintext data.

[0083] The encryption information includes, for example, an encryption identifier, a flow identifier, an offset, a length, and an authentication code.

[0084] The encryption identifier includes encryption information indicating whether the frame is encrypted or not, and encryption method information indicating the encryption method applied to the frame if the frame is encrypted.

[0085] The flow identifier is information for identifying, for example, an application that performs communication or a communication flow (a flow to which a frame belongs) used within the application.

[0086] The offset includes position information indicating the position of the frame counted from the beginning of the communication flow. This position information may be, for example, the number of bytes since the start of communication. Note that if there is a restriction on the number of bits allocated to the position information, it may be cyclic. Also, depending on the encryption method, the position information may be the number of transmitted frames (packets) instead of the number of bytes.

[0087] The length indicates the length of the encrypted data or the length of the entire frame. The length is optional and does not necessarily have to be included in the encryption information.

[0088] The authentication code is used to detect whether the frame has been tampered with during transmission. The authentication code is generated (calculated) using the information contained in the frame and key data. The authentication code is optional and does not necessarily have to be included in the encrypted information.

[0089] Although the L2 encryption method has been described here, L3 encryption may also be specified as the encryption method. Fig. 8 shows an example of a packet format in Layer 3. Fig. 8 shows a plaintext packet containing plaintext data and a packet (encrypted packet) that has undergone L3 encryption as encryption at Layer 3. In L3 encryption, headers of Layers 4 and above are simply treated as plaintext data. As shown in Fig. 8, when a plaintext packet is encrypted, encryption information is added to the encrypted packet along with encrypted data obtained by encrypting the plaintext data.

[0090] Furthermore, the encryption method may be specified as MACsec, IPsec, or the like. When the encryption method is MACsec, the MACsec Ethertype of 0x88e5 and the E bit in the TCI field may be used as the encryption identifier. Furthermore, the value of the SCI field, the value of the AN field, or a combination of these may be used as the flow identifier. Although there is no field directly corresponding to the offset, the offset may be represented, for example, in the PN field. Furthermore, the SL field is used when the length is less than 48 bytes, but the SL field may be extended to represent the length. The authentication code may be represented in the ICV field. Note that new fields may be provided for fields not present in MACsec.

[0091] Furthermore, when IPsec ESP (Encapsulating Security Payload) is used as the encryption method, the protocol number of the IP header can be 50, which can be used as the encryption identifier. Furthermore, SPI (Security Parameter Index) can be used as the flow identifier. The offset can be expressed using a Sequence Number. Furthermore, the offset may be expressed using an Extended Sequence Number option.

[0092] Furthermore, TLS may be specified as the encryption method. In this case, for example, the transmission control unit 212 and the reception control unit 204 may process communication protocols up to layer 4, and then encrypt or decrypt the communication data obtained by this processing.

[0093] 6 again, the write position and read position indicate the position where new key data starts to be written and the position where key data to be used in the next encryption process is read in the first key storage unit 213. That is, the write position corresponds to the start position where the next writing will be performed, and the read position corresponds to the start position where the next reading will be performed.

[0094] 9, the first key storage unit 213 has a fixed buffer area for each flow, and the buffer area is used as a ring buffer. For this reason, the first key storage unit 213 is managed using a write position and a read position.

[0095] Fig. 10 shows an example of management of the ring buffer (first key storage unit 213) using the write position and read position described above. In the example shown in Fig. 10, an area of ​​128 KiB (0x00000 to 0x1FFFF) is used using the write position and read position. Specifically, when the write position is 0x00000 and the read position is 0x0943E, 0x00000 to 0x0943D is the area for key data that has already been used (area for which key data has been used), and 0x0943E to 0x1FFFF is the area for key data that has not yet been used (area for which key data is unused).

[0096] 6, the number of cycles indicates the number of times that reading from the ring buffer has cycled, and the buffer size indicates the size (length) of the ring buffer.

[0097] When the above-described transmission side setting process is executed, the key data management unit 214 (i.e., the second key management data shown in Fig. 6) is initialized. The values ​​of the write position, read position, and circulation count included in the second key management data shown in Fig. 6 are updated by executing the key data transfer process and frame transmission process described later.

[0098] Next, an example of the processing procedure of the above-mentioned receiving-side setting processing will be described with reference to the flowchart of Fig. 11. In the description of Fig. 11, the encryption communication device 20 is intended to be the receiving-side encryption communication device 20b, and the other encryption communication device 20 is intended to be the transmitting-side encryption communication device 20a.

[0099] First, the communication application unit 218 included in the encryption communication device 20 is realized by the operation of an application on the encryption communication device 20 that starts communication with another encryption communication device 20, and operates to receive communication data transmitted from the other encryption communication device 20 and execute processing on the communication data. The communication application unit 218 sets up the communication control unit 219 to receive communication data transmitted from the other encryption communication device 20 (step S11).

[0100] In step S11, a flow to which frames transmitted from other encryption communication devices 20 belong (that is, a flow of communication performed by the communication application unit 218) is set.

[0101] Next, the communication application unit 218 sets the flow identification unit 203 (step S12). In step S12, flow identification setting information related to flow identification in the flow identification unit 203 is transmitted to the communication control unit 219, and the flow identification unit 203 is set based on the flow identification setting information.

[0102] Here, Fig. 12 shows an example of settings of the flow identification unit 203. When using stream identification (flow identification) of IEEE 802.1CB as shown in Fig. 12, a flow is defined using a MAC address, a VLAN (Virtual Local Area Network) ID, etc.

[0103] In the example shown in Figure 12, for example, if the destination MAC address is "AA-BB-CC-DD-EE-01" and the VLAN ID is "10", it is identified as (the flow) with the flow identifier "0". Also, for example, if the source MAC address is "AA-BB-CC-DD-EE-02" and the VLAN ID is "20", it is identified as (the flow) with the flow identifier "1".

[0104] The flow may be identified from the MACsec or IPsec header information described above.

[0105] 4, the encryption communication device 20 (receiving-side encryption communication device 20b) is notified of a QKD key identifier from the other encryption communication device 20 (sending-side encryption communication device 20a). Returning to Fig. 11 again, the communication application unit 218 acquires the QKD key identifier notified from the other encryption communication device 20 (step S13).

[0106] Next, communication application unit 218 instructs key management application unit 220 to acquire key data (step S14).

[0107] When the process of step S14 is executed, the key management application unit 220 acquires key data via the key acquisition unit 221 (step S15). Note that the process of acquiring key data is the same as the process described in the transmission-side setting process above, and therefore a detailed description thereof will be omitted here.

[0108] After the process of step S15 is executed, the processes of steps S16 and S17, which are similar to the processes of steps S4 and S5 shown in FIG. 4, are executed.

[0109] When the above-described receiving-side setting process is executed, the key data management unit 214 (that is, the second key management data shown in FIG. 6) is initialized in the same manner as in the transmitting-side setting process.

[0110] Next, an example of the processing procedure of the above-mentioned key data transfer processing will be described with reference to the flowchart of Fig. 13. Note that the key data transfer processing is executed both by the encryption communication device 20 operating as the encryption communication device 20a on the sending side and by the encryption communication device 20 operating as the encryption communication device 20b on the receiving side.

[0111] In this embodiment, key data transfer is performed based on a key transfer request from the key data management unit 214 included in the network interface 104. Specifically, key data transfer is initiated when the CPU 101 receives an interrupt from the key data management unit 214 via the internal bus. Although an interrupt is used as an example here, key data transfer may also be performed in accordance with a polling operation by the CPU 101. In this case, the key data management unit 214 writes a value to a status field of a key transfer descriptor entry (described later), and the host detects a change in that value, thereby performing a polling operation.

[0112] First, key management application unit 220 detects a key transfer request from key data management unit 214 via key transfer control unit 222. The key transfer request includes a flow identifier, and key management application unit 220 identifies the flow to which key data is to be transferred (i.e., the flow that is the target of the key transfer request) based on the flow identifier (step S21). In the following description, the flow identified in step S21 will be referred to as the target flow.

[0113] The key management application unit 220 determines whether or not there is sufficient key data for the target flow in the second key storage unit 223 (step S22).

[0114] As described above, the key management application unit 220 manages the key data stored in the second key storage unit 223 by using the first key management data shown in Fig. 5. In this case, in step S22, by referring to the length and transferred data size included in the first key management data in association with the flow identifier of the target flow, it is determined whether or not the second key storage unit 223 stores enough key data to transfer the data from the host to the network interface 104.

[0115] If it is determined that there is not enough key data for the target flow in the second key storage unit 223 (NO in step S22), the key management application unit 220 instructs the key acquisition unit 221 to acquire key data (key data for the target flow), and the key data is acquired via the key acquisition unit 221 (step S23). The key data acquired in step S23 is stored in the second key storage unit 223 (step S24).

[0116] On the other hand, if it is determined that there is sufficient key data for the target flow in the second key storage unit 223 (YES in step S22), the processes of steps S23 and S24 are not executed.

[0117] Next, the key management application unit 220 instructs the key data transfer unit 215 to transfer the key data via the key transfer control unit 222 (step S25).

[0118] When the processing of step S25 is executed, key data is transferred from the second key storage unit 223 (i.e., the host's main memory 102) to the first key storage unit 213 (i.e., the network interface 104) in accordance with instructions from the key management application unit 220 (step S26).

[0119] An overview of key data transfer in this embodiment will be described below with reference to Fig. 14. First, in this embodiment, as shown in Fig. 14, a key transfer descriptor ring is held in the system memory (main memory 102), and the key data transfer unit 215 is controlled using this key transfer descriptor ring. The key transfer descriptor ring has eight descriptor rings corresponding to channels 0 to 7. Here, it is assumed that channel 7 (the descriptor ring corresponding to it) is used to transfer key data with the highest priority, and channel 0 (the descriptor ring corresponding to it) is used to transfer key data with the lowest priority. The descriptor ring corresponding to each channel has the form of a ring buffer and is made up of a plurality of descriptor entries.

[0120] 15 shows an example of one descriptor entry in the key transfer descriptor ring shown in FIG. 14. As shown in FIG. 15, the descriptor entry includes a key data transfer source address, a key data length, a key data transfer destination address, and a status. The key data transfer source address indicates the address (position) of the key data stored in the second key storage unit 223. The key data length indicates the length of the key data to be transferred from the key data transfer source address. The key data transfer destination address indicates the starting address when writing the key data to the first key storage unit 213. The status includes information indicating whether the key data transfer has been completed successfully and information indicating whether an error has occurred in the key data transfer.

[0121] As shown in FIG. 14, the key management application unit 220 refers to the first key management data and notifies the key transfer control unit 222 of the priority associated with the flow identifier of the target flow (priority of the target flow) (step S201).

[0122] Next, key transfer control unit 222 identifies a channel for transferring key data based on the priority of the target flow notified by key management application unit 220. In this case, key transfer control unit 222 can use, for example, a channel assigned the same number as the priority of the target flow notified by key management application unit 220.

[0123] Furthermore, the key transfer control unit 222 performs settings on the descriptor entry of the descriptor ring corresponding to the identified channel (step S202). In this case, the key transfer control unit 222 clears the status (field) and then sets the key data source address, key data length, and key data destination address (fields). The key data source address is identified, for example, from an address and transferred data size included in the first key management data in association with the flow identifier of the target flow. However, the flow identifier of the target flow may be set (specified) instead of the key data source address. The key data length is, for example, a predetermined value. The key data destination address is identified, for example, based on the second key management data shown in FIG. 6 and the buffer area of ​​the target flow shown in FIG. 9. Specifically, the key data destination address corresponds to an address obtained by adding the write location (write location included in the second key management data) obtained from the key data management unit 214 to the start address of the area (buffer area) of the first key storage unit 213 where the key data of the target flow is stored.

[0124] Next, the key transfer control unit 222 instructs the key data transfer unit 215 to process the descriptor setting configured for the descriptor entry using the channel number (number assigned to the channel) and the descriptor number (number assigned to the descriptor entry) (step S203).

[0125] In this case, the key data transfer unit 215 refers to the settings for the descriptor entry that constitutes the descriptor based on an instruction (channel number or descriptor number) from the key transfer control unit 222, and starts transferring the key data.

[0126] Specifically, the key data transfer unit 215 reads the key data stored in the second key storage unit 223 implemented in the main memory 102 of the host, for example, by DMA, without processing by the CPU 102 (step S204). Such reading of the key data is performed based on the key data transfer source address and key data length set in the above-mentioned descriptor entry.

[0127] The key data thus read out from second key storage unit 223 is transferred to key data reception unit 216 (step S205).

[0128] The above-mentioned key data transfer and the frame transfer described below are arbitrated by the priority arbitration unit 217. According to this arbitration by the priority arbitration unit 217, transfers with higher priority (i.e., higher channel numbers) by the frame transfer unit 208 and the key data transfer unit 215 are given priority. Furthermore, if the priorities are the same, the priority arbitration unit 217 performs arbitration using, for example, a round-robin method, or gives priority to transferring the key data. In this case, the frame transfer unit 208 and the key data transfer unit 215 each transmit the channel numbers of the channels on which they wish to transfer to the priority arbitration unit 217, and operate to perform the transfer permitted by the priority arbitration unit 217.

[0129] Next, key data receiving unit 216 receives the key data transferred from key data transferring unit 215, and writes the key data to first key storage unit 213 (step S206). In this case, key data receiving unit 216 writes the key data to (the area of ​​first key storage unit 213 specified by) the key data transfer destination address set in the above-mentioned descriptor entry.

[0130] Returning to Figure 13 again, as a result of the processing using the descriptor, information indicating whether the transfer of the key data was completed successfully or not is written to the status (field) included in the descriptor entry, and the status is updated (step S27).

[0131] After the process of step S27 is executed, a transfer process completion notice indicating the completion of the key data transfer (processing instructed by the descriptor) is sent to key transfer control unit 222 by interrupt (step S28). Once the result of the process is confirmed by the status included in the descriptor entry, the used descriptor entry becomes available for reuse in subsequent key data transfers.

[0132] Meanwhile, the key data receiving unit 216 updates the write position of the second key management data managed in the key data managing unit 214 (the write position included in the second key management data in association with the flow identifier of the target flow) (step S29). In step S29, the write position is updated by advancing it by the amount of the key data written to the first key storage unit 213.

[0133] Here, the key data management unit 214 determines whether the area into which new key data can be transferred (i.e., the amount of key data that can be transferred) is, for example, 64 KiB or more, based on the write location and read location included in the second key management data in association with the flow identifier of the target flow (step S30).

[0134] If it is determined that the transferable amount of key data is 64 KiB or more (YES in step S30), the key data management unit 214 issues a new key transfer request including the flow identifier of the target flow (step S31). In other words, the key data management unit 214 requests the transfer of key data based on the amount of key data stored in the first key storage unit 213. When the processing of step S31 has been executed, the process returns to step S21 and is repeated.

[0135] On the other hand, if it is determined that the transferable amount of key data is not 64 KiB or more (that is, less than 64 KiB) (NO in step S30), the key data transfer process is ended.

[0136] The 64 KiB used in the determination process in step S30 is an example, and it is sufficient to determine in step S30 whether or not the transferable amount of key data is equal to or greater than a certain value.

[0137] When the above-mentioned key data transfer process is executed, key data can be sequentially transferred from the host's main memory 102 to the network interface 104 in response to a key transfer request from the network interface 104 side (key data management unit 214 included in the network interface 104).

[0138] It should be noted that in the present embodiment, a key transfer request requests key data that is longer than the key data used for one encryption or decryption process executed on a frame (encryption or decryption process for one frame or communication transfer unit). In other words, in this embodiment, key data is read out sequentially from the first key storage unit 213 each time an encryption or decryption process is executed, but in order to reduce the number of times key data is transferred, it is preferable to transfer key data that is long enough to allow multiple encryption or decryption processes to be executed at once.

[0139] Next, an example of the processing procedure of the above-mentioned frame transmission processing will be described with reference to the flowchart of Fig. 16. In the description of Fig. 16, the encryption communication device 20 refers to the encryption communication device 20a on the sending side, and the other encryption communication device 20 refers to the encryption communication device 20b on the receiving side.

[0140] First, the communication application unit 218 included in the encrypted communication device 20 generates communication data to be transmitted to another encrypted communication device 20, and instructs the communication control unit 219 to transmit the communication data (step S41). Note that data of a frame for transmitting the communication data generated by the communication application unit 218 (hereinafter referred to as a transmission frame) is stored in the system memory (main memory 102).

[0141] In step S41, the communication application unit 218 notifies the communication control unit 219 of information indicating the priority of the communication (transmission frame) and information indicating the flow of the communication, along with the communication data.

[0142] Next, the communication control unit 219 adds a header to the communication data as necessary, and instructs the frame transfer unit 208 to transfer the transmission frame (step S42). After the process of step S42 is executed, the frame transfer unit 208 transfers the transmission frame in accordance with the instruction from the communication control unit 219 (step S43).

[0143] An overview of the transfer of a transmit frame will be described below with reference to Fig. 17. First, in this embodiment, as shown in Fig. 17, a transmit frame descriptor is held in the system memory (main memory 102), and the transmit frame transfer unit 208a in the frame transfer unit 208 is controlled using the transmit frame descriptor. The transmit frame descriptor has eight descriptors corresponding to channels 0 to 7. Here, it is assumed that channel 7 (the descriptor corresponding to it) is used to transfer a transmit frame with the highest priority, and channel 0 (the descriptor corresponding to it) is used to transfer a transmit frame with the lowest priority. The descriptor corresponding to each channel has the form of a ring buffer, and is made up of a plurality of descriptor entries.

[0144] Note that Figure 18 shows an example of one descriptor entry in the transmit frame descriptor ring shown in Figure 17. As shown in Figure 18, the descriptor entry includes a frame source address, a frame length, a flow identifier, and a status. The frame source address indicates the starting address (position) of the transmit frame stored in the system memory. The frame length indicates the length of the transmit frame to be transferred from the frame source address. The flow identifier indicates the flow to which the transmit frame belongs. The status includes information indicating whether the transfer of the transmit frame has been completed successfully or whether an error has occurred in the transfer of the transmit frame.

[0145] 17, the communication control unit 219 specifies a channel for transferring a transmission frame based on (information about) the priority of the transmission frame notified by the communication application unit 218. In this case, the communication control unit 219 can use, for example, a channel assigned with the same number as the priority of the transmission frame notified by the communication application unit 218.

[0146] Furthermore, the communication control unit 219 performs settings for the descriptor entry of the descriptor ring corresponding to the identified channel (step S401). In this case, the communication control unit 219 clears the status (field) and then sets the frame source address, frame length, and flow identifier (fields).

[0147] Next, the communication control unit 219 instructs the frame transfer unit 208 to perform the descriptor processing (frame transmission processing) for the descriptor entry set using the channel number (number assigned to the channel) and the descriptor number (number assigned to the descriptor) (step S402).

[0148] In this case, the transmission frame transfer unit 208a refers to the settings for the descriptor entry that constitutes the descriptor based on an instruction (channel number or descriptor number) from the communication control unit 219, and starts transferring the transmission frame.

[0149] Here, as described above, the frame transfer and the key data transfer are arbitrated by the priority arbitration unit 217. When the transfer of the transmission frame (transmission on the channel instructed to transfer) is permitted by the priority arbitration unit 217, the transmission frame transfer unit 208a reads the transmission frame stored in the system memory via the internal bus (PCIe bus) by DMA without processing by the CPU 102 (step S403). Such reading of the transmission frame is performed based on the frame transfer source address and frame length set in the above-mentioned descriptor entry.

[0150] The transmission frame thus read from the system memory is set with attached information and output to the encryption determination unit 209 (step S404). FIG. 19 shows an example of attached information set in the transmission frame. In the example shown in FIG. 19, the attached information includes a priority identifier indicating the priority of the transmission frame and a flow identifier for identifying the flow to which the transmission frame belongs. As shown in FIG. 19, the attached information is added to the beginning of the transmission frame. In other words, the attached information is transmitted in association with the frame.

[0151] Returning to Figure 16 again, as a result of processing using the descriptor, information indicating whether the transfer of the transmission frame was completed successfully or not is written to the status (field) included in the descriptor entry, and the status is updated (step S44).

[0152] When the process of step S44 is executed, a transfer process completion notice indicating the completion of the transfer of the transmission frame (the process instructed by the descriptor) is sent to the communication control unit 219 by interrupt (step S45). When the result of the process is confirmed by the status included in the used descriptor entry, the status (field) is cleared and the used descriptor entry becomes available for the transfer of subsequent transmission frames.

[0153] Next, the encryption determination unit 209 determines whether the transmission frame is to be encrypted (i.e., whether the transmission frame belongs to a flow to be encrypted) (step S46). The process of step S46 is executed based on the attached information set in the transmission frame and the second key management data managed in the key data management unit 214. Specifically, the encryption determination unit 209 extracts a flow identifier from the attached information set in the transmission frame and acquires the encryption method included in the second key management data in association with the flow identifier. If the acquired encryption method includes information related to encryption processing, such as "L2 encryption·OTP," the encryption determination unit 209 determines that the transmission frame is to be encrypted. On the other hand, if the flow identifier extracted from the attached information is not set (does not exist) in the second key management data or if the encryption method corresponding to the flow identifier is not set in the second key management data, the encryption determination unit 209 determines that the transmission frame is not to be encrypted.

[0154] If it is determined that the transmission frame is to be encrypted (YES in step S46), the encryption processing unit 210 executes encryption processing on the transmission frame (step S47).

[0155] The encryption process executed in step S47 will be described below with reference to Fig. 20. Fig. 20 shows an example of the internal configuration of the encryption processing unit 210.

[0156] As shown in FIG. 20, the encryption processing unit 210 includes a key data selection unit 210a, a calculation unit 210b, a read position update unit 210c, and an encryption information addition unit 210d.

[0157] The key data selection unit 210a reads (selects) key data from the first key memory unit 213 based on the flow identifier (hereinafter referred to as the target flow identifier) ​​included in the ancillary information set in the transmission frame and the read position of the target flow identifier in the key data management unit 214 (i.e., the read position included in the second key management data in correspondence with the target flow identifier).

[0158] The calculation unit 210b encrypts the transmission frame using the key data selected by the key data selection unit 210a. This encryption is performed in accordance with the encryption method (the encryption method corresponding to the flow identifier) ​​included in the second key management data managed in the key data management unit 214.

[0159] The encryption scope differs depending on the encryption method corresponding to the target flow identifier. For example, if the encryption method is L2 encryption, the data after the L2 header is encrypted as plaintext data. If the encryption method is L3 encryption, the data after the L3 header is encrypted as plaintext data.

[0160] Furthermore, when a one-time pad is employed, encryption is performed by performing an XOR (exclusive OR) operation on the plaintext data and the key data, i.e., encrypted data is obtained by performing an XOR operation.

[0161] Furthermore, the calculation unit 210b performs calculations using the key data and the transmission frame to generate authentication data.

[0162] When the processing by the calculation unit 210b is completed, the read position update unit 210c updates the read position included in the second key management data by advancing the read position by the length of the key data used for encryption in the calculation unit 210b.

[0163] When the process of step S47 is executed as described above, an encrypted frame including encrypted data and authentication data is generated.

[0164] Next, the key data management unit 214 determines whether the area into which new key data can be transferred (i.e., the amount of key data that can be transferred) is, for example, 64 KiB or more, based on the write location and read location included in the second key management data in association with the target flow identifier (step S48).

[0165] If it is determined that the transferable amount of key data is 64 KiB or more (YES in step S48), the key data management unit 214 issues a new key transfer request including the target flow identifier (step S49). Note that when the processing of step S49 is executed, the key data transfer processing shown in FIG. 13 is executed.

[0166] On the other hand, if it is determined that the transferable amount of key data is not 64 KiB or more (that is, less than 64 KiB) (NO in step S48), the process of step S49 is not executed.

[0167] Next, the encryption information adding unit 210d adds (a field of) encryption information to the encrypted frame (step S50). The encryption information includes the encryption identifier, flow identifier, offset, length, and authentication code described above. In this case, for example, before the encryption process is performed, the buffer size can be multiplied by the number of cycles, and the read position can be added to the result of the multiplication to calculate a value, and the calculated value can be set as the offset.

[0168] The encrypted frame to which the encryption information has been added is set with auxiliary information and output to the transmission frame storage unit 211. In the following description, for convenience, the encrypted frame output to the transmission frame storage unit 211 will be referred to as the transmission frame.

[0169] Here, the transmission frame storage unit 211 distributes the transmission frames based on the priority identifiers included in the attached information, and stores the attached information and transmission frames in order in queues prepared for each priority (step S51).

[0170] The transmission control unit 212 reads the attached information and the transmission frame from each queue of the transmission frame storage unit 211, and executes transmission control based on the TSN (step S52). In this case, processes such as EST, which controls frame transmission by opening and closing a gate based on priority, Frame Preemption, which interrupts the transmission of a low-priority frame and transmits a high-priority frame, and Frame Replication, which duplicates and transmits a frame, are executed using the attached information and the transmission frame.

[0171] When the process of step S52 is executed, the transmission control unit 212 deletes the attached information and outputs the transmission frame to the communication unit 201. The communication unit 201 executes communication protocol processing of the data link layer and physical layer on the transmission frame output from the transmission control unit 212, thereby transmitting the transmission frame via the network (step S53).

[0172] According to the above-described frame transmission process, the transmission frame can be encrypted using the key data transferred from the second key memory unit 223 to the first key memory unit 213 by the key data transfer process, and the encrypted transmission frame can be transmitted to another encryption communication device 20.

[0173] If it is determined in step S46 that the transmission frame is not to be encrypted (NO in step S46), the processes in steps S47 to S50 are not executed, and the processes in and after step S51 are executed.

[0174] Next, an example of the processing procedure of the above-mentioned frame reception processing will be described with reference to the flowchart of Fig. 21. In the description of Fig. 21, the encryption communication device 20 refers to the encryption communication device 20b on the receiving side, and the other encryption communication device 20 refers to the encryption communication device 20a on the transmitting side.

[0175] First, the communication unit 201, which performs processing of the physical layer and the data link layer, receives a frame transmitted from another encryption communication device 20 via the network (step S61). In the following description, the frame received in step S61 is referred to as a received frame.

[0176] Next, the priority identification unit 202 identifies the priority of the received frame (the priority assigned to the flow to which the received frame belongs) (step S62). The process of step S62 is performed based on, for example, the value of the PCP (Priority Code Point) of the VLAN defined in IEEE 802.1Q in the frame. The priority information identified in step S62 (the priority identifier for identifying the priority) is set as ancillary information of the received frame. The value of the PCP of the VLAN can also be used as the priority identifier.

[0177] After step S62, the flow identification unit 203 identifies the flow to which the received frame belongs (step S63). The process of step S63 (i.e., flow identification) may be performed using stream identification defined in IEEE 802.1CB. In this case, the flow is identified using the field values ​​in the received frame. The field values ​​during reception include, for example, the destination MAC address, source MAC address, VLAN ID, destination IP address, source IP address, DSCP, transport protocol, destination port number, and source port number.

[0178] The flow identifier (information for identifying a flow) uses, for example, the value of a stream handle defined in IEEE 802.1CB. Information necessary for flow identification is set in advance in the flow identification unit 203 from the communication application unit 218 via the communication control unit 219. The information necessary for flow identification is, for example, information indicating the correspondence between a combination of field values ​​in a received frame and a flow identifier, as shown in Fig. 12.

[0179] The flow identification unit 203 may also identify (recognize) MACsec or IPsec flows. In this case, the flow is identified using the values ​​of the MACsec SCI and AN fields and the IPsec SPI field in the received frame, and the values ​​of these fields or part of the values ​​of these fields are used as the flow identifier.

[0180] As described above, information on the flow identified by the flow identification unit 203 (flow identifier) ​​is set as auxiliary information of the received frame.

[0181] Next, the decryption determination unit 205 determines whether the received frame is a target for decryption processing (i.e., whether the received frame belongs to a flow to be decrypted) (step S64). The processing of step S64 is executed by extracting a flow identifier from the attached information set in the received frame and acquiring (information about) the encryption method corresponding to the flow identifier included in the second key management data managed in the key data management unit 214. Specifically, if information for performing encryption processing such as "L2 encryption·OTP" is registered as the encryption method corresponding to the flow identifier extracted from the attached information, the decryption determination unit 205 determines that the received frame is a target for decryption processing. On the other hand, if the flow identifier extracted from the attached information is not set (does not exist) in the second key management data or if (information about) the encryption method corresponding to the flow identifier is not set in the second key management data, the decryption determination unit 205 determines that the received frame is not a target for decryption.

[0182] If it is determined that the received frame is a target for decoding processing (YES in step S64), the decoding processing unit 206 executes decoding processing on the received frame (step S65).

[0183] The decoding process executed in step S65 will be described below with reference to Fig. 22. Fig. 22 shows an example of the internal configuration of the decoding processing unit 206.

[0184] As shown in FIG. 22, the decryption processing unit 206 includes a key data selection unit 206a, a calculation unit 206b, a read position update unit 206c, and an encryption information removal unit 206d.

[0185] The key data selection unit 206a reads (selects) key data from the first key memory unit 213 based on the flow identifier (hereinafter referred to as the target flow identifier) ​​included in the ancillary information set in the received frame, the corresponding read position (the read position corresponding to the flow identifier) ​​included in the second key management data managed in the key data management unit 214, and the offset value included in the received frame.

[0186] The offset value included in the received frame is used to detect any change in the received frame order or loss of a frame that may occur during the decoding process.

[0187] The calculation unit 206b decrypts the received frame using the key data selected by the key data selection unit 206a. This decryption is performed in accordance with the encryption method (the encryption method corresponding to the flow identifier) ​​included in the second key management data managed in the key data management unit 214.

[0188] The decryption target range differs depending on the encryption method corresponding to this flow identifier, and the calculation unit 206b identifies the area of ​​encrypted data in the received frame based on (information about) the encryption method and performs decryption.

[0189] Furthermore, when a one-time pad is employed, decryption is performed by performing an XOR operation on the encrypted data and the key data, i.e., the plaintext data is obtained by performing an XOR operation.

[0190] Furthermore, the calculation unit 206b checks the authentication data included in the encryption information added to the received frame (encrypted frame). In this case, the calculation unit 206b performs a calculation using the key data and the received frame, and if the calculation result does not match the authentication data, it determines that the frame has been tampered with and discards the received frame.

[0191] When the processing by the calculation unit 206b is completed, the read position update unit 206c updates the read position included in the second key management data by the length of the key data used for decryption in the calculation unit 206b (i.e., up to the point where the calculation unit 206c has finished using for decryption).

[0192] When the process of step S65 is executed as described above, a plaintext frame containing plaintext data is generated.

[0193] Next, the key data management unit 214 determines whether the area into which new key data can be transferred (i.e., the amount of key data that can be transferred) is, for example, 64 KiB or more, based on the write location and read location included in the second key management data in association with the target flow identifier (step S66).

[0194] If it is determined that the transferable amount of key data is 64 KiB or more (YES in step S66), the key data management unit 214 issues a new key transfer request including the target flow identifier (step S67). Note that when the processing of step S67 is executed, the key data transfer processing shown in FIG. 13 is executed.

[0195] On the other hand, if it is determined that the transferable amount of key data is not 64 KiB or more (that is, less than 64 KiB) (NO in step S6), the process of step S67 is not executed.

[0196] Next, the encryption information removal unit 206d removes (fields of) encryption information such as the encryption identifier, flow identifier, offset, length, and authentication code (step S68).

[0197] The plaintext frame from which the encryption information has been removed has auxiliary information set therein and is output to the received frame storage unit 207. In the following description, the plaintext frame output to the received frame storage unit 207 will be referred to as the received frame for convenience.

[0198] Here, the received frame storage unit 207 sorts the received frames based on the priority identifiers included in the ancillary information, and stores the ancillary information and received frames in order in queues prepared for each priority (step S69).

[0199] When the frame data transfer unit 208 detects that a received frame has been stored (that is, exists) in the received frame storage unit 207, it writes the received frame to the main memory 102 via the internal bus and transfers the received frame (step S70).

[0200] An overview of the transfer of received frames will be described below with reference to Fig. 23. First, in this embodiment, as shown in Fig. 23, receive frame descriptors are held in the system memory (main memory 102), and the receive frame transfer unit 208b in the frame transfer unit 208 is controlled using the receive frame descriptors. The receive frame descriptors have eight descriptors corresponding to channels 0 to 7. Here, it is assumed that channel 7 (the descriptor corresponding to it) is used to transfer receive frames with the highest priority, and channel 0 (the descriptor corresponding to it) is used to transfer receive frames with the lowest priority. The descriptor corresponding to each channel has the form of a ring buffer and is made up of multiple descriptor entries.

[0201] 24 shows an example of one descriptor entry in the receive frame descriptor ring shown in FIG. 23. As shown in FIG. 24, the descriptor entry includes a frame transfer destination address, a frame length, a flow identifier, and a status. The frame transfer destination address indicates the address (location) in the system memory where the received frame is stored. The frame length indicates the length of the received frame to be transferred to the frame transfer destination address. The flow identifier indicates the flow to which the received frame belongs. The status includes information indicating whether the transfer of the received frame has been completed successfully or whether an error has occurred in the transfer of the received frame. The communication control unit 219 clears the status of each descriptor entry in advance during initialization processing or upon completion of transfer processing, reserves an area in the main memory 102 sufficient to store the received frame, and sets the starting address of the area to the frame transfer destination address.

[0202] As shown in FIG. 23, the received frame transfer unit 208b reads out the received frame stored in the received frame storage unit 207 from the received frame storage unit 207 (step S701).

[0203] The received frame transfer unit 208b monitors which queue, for each priority, the received frame storage unit 207 contains. If there is a queue containing a received frame, it selects the queue with the highest priority. Then, it identifies a channel for transferring the received frame based on the priority (information) contained in the attached information set in the received frame or the priority (information) corresponding to the queue. In this case, the received frame transfer unit 208b can use a channel assigned the same number as the priority contained in the attached information.

[0204] As described above, the transfer of the frame and the transfer of the key data are arbitrated by the priority arbitration unit 217. When the transfer of the received frame is permitted by the priority arbitration unit 217, the received frame transfer unit 208b writes the received frame read from the received frame storage unit 207 by DMA to the location specified by the frame transfer destination address of the descriptor entry in the system memory (step S702).

[0205] Next, the received frame transfer unit 208b sets a descriptor entry in the descriptor ring corresponding to the identified channel (step S703). In this case, the received frame transfer unit 208b sets (the fields of) the frame length and flow identifier. Furthermore, the received frame transfer unit 208b sets (the fields of) the status as a result of processing using the descriptor, such as information indicating whether the transfer of the received frame has ended normally.

[0206] When the transfer of the received frame (the process instructed by the descriptor) is completed, a transfer process completion notification is sent by an interrupt to the communication control unit 219. In this case, the communication control unit 219 refers to the status field of the descriptor entry of each channel to identify the descriptor entry transferred by the received frame transfer unit 208b, and instructs the communication control unit 219 to perform the descriptor processing set for the descriptor entry using the channel number (the number assigned to the channel) and the descriptor number (the number assigned to the descriptor) (step S704).

[0207] When the communication control unit 219 detects the transfer processing completion notification, it refers to the status field of the descriptor entry of the channel to identify the descriptor entry to which the received frame transfer unit 208b performed the transfer. It then refers to the descriptor entry to identify the location of the received frame written in the system memory from the frame transfer destination address and frame length. It then reads the received frame from the system memory and outputs the received frame to the communication application unit 218 (step S705). At this time, a flow identifier may also be acquired at the same time. When the processing result of the used descriptor entry is confirmed based on the status included in the descriptor entry, the status field is cleared, making the descriptor entry available for subsequent transfer of received frames. The communication control unit 219 then notifies the received frame transfer unit 208b that processing of the descriptor entry has been completed, using the channel number (the number assigned to the channel) and the descriptor number (the number assigned to the descriptor entry).

[0208] Returning to FIG. 21, the communication application unit 218 processes the received frame (communication data) output from the communication control unit 219 (step S71).

[0209] According to the frame reception process described above, the received frame can be decrypted using the key data transferred from the second key storage unit 223 to the first key storage unit 213 by the key data transfer process, and the decrypted received frame can be processed by the communication application unit 218.

[0210] As described above, the network interface 104 (communication control device) of this embodiment acquires a frame (data) transmitted from an encryption communication device 20 (first communication device) to another encryption communication device 20 (second communication device) via a network, or a frame (data) transmitted from the other encryption communication device 20 to the encryption communication device 20, and if the acquired frame belongs to a flow to be encrypted or decrypted, performs encryption or decryption processing on the frame using key data, requests the transfer of key data for each flow via the internal bus of the encryption communication device 20, and stores the key data transferred in response to the request in the first key memory unit 213.

[0211] In this embodiment, the internal bus includes a PCIe bus, and the key data is transferred from a host (the CPU 101 and the main memory 102) that constitutes the encryption communication device 20.

[0212] In this embodiment, with this configuration, when an encryption communication method that switches keys (data) sequentially is used, low-latency communication can be achieved by transferring the key data from the host to the network interface 104 in advance.

[0213] Furthermore, in this embodiment, the transfer of key data is requested based on second key management data (management data for managing key data stored in the first key storage unit 213) managed in the key data management unit 214. Furthermore, the transfer of key data is controlled based on the priority assigned to the flow to which the frame belongs. Furthermore, in this embodiment, the transfer of key data is requested based on the amount of key data (e.g., the amount that can be transferred) stored in the first key storage unit 213. Furthermore, in this embodiment, the transfer of key data that is longer than the key data used to perform one encryption or decryption process on a frame is requested.

[0214] In this embodiment, with this configuration, it is possible to efficiently transfer key data to achieve the above-mentioned low-delay communication.

[0215] In this embodiment, the encryption processing unit 210 shown in Fig. 20 and the decryption processing unit 206 shown in Fig. 22 have been described as separate processing units, but since the units 210a to 210c shown in Fig. 20 and the units 206a to 206c shown in Fig. 22 have common functions, the encryption processing unit 210 and the decryption processing unit 206 may be configured as an integrated unit like the encryption / decryption processing unit shown in Fig. 25. The encryption processing unit 210, the decryption processing unit 206, and the encryption / decryption processing unit can all be called an encryption processing unit.

[0216] Furthermore, in this embodiment, a configuration has been described in which key data is directly acquired from QKD device 10, but a configuration is also possible in which key data acquired from QKD device 10 is stored in storage 103 connected to expansion bus 106, and key data is acquired from storage 103 (that is, key data acquired from storage 103 is stored in second key storage unit 223 of the host). In this case, key management application unit 220 may manage the file name of the key data stored in storage 103, the position of the key data in storage 103, and information on transferred (used) key data (information on how much key data has been read), etc. In this way, key management application unit 220 can read key data from storage 103 to second key storage unit 223 by instructing key acquisition unit 221 according to the transfer status (usage status) of the key data, and transfer the key data from second key storage unit 223 (that is, the host) to first key storage unit 213 (that is, network interface 104).

[0217] Other modifications of this embodiment will be described below, including first to third modifications.

[0218] First, a first modified example will be described with reference to Fig. 26. Fig. 26 is a block diagram showing an example of the functional configuration of an encryption communication device 20 according to the first modified example. In Fig. 26, the same parts as those in Fig. 3 above are given the same reference numerals, and detailed description thereof will be omitted. Here, the parts that differ from Fig. 3 will be mainly described.

[0219] As shown in Figure 26, the encryption communication device 20 of the first variant includes, as functional units realized by the host, a decryption determination unit 224 (second decryption determination unit), a decryption processing unit 225 (second decryption processing unit), an encryption determination unit 226 (second encryption determination unit), and an encryption processing unit 227 (second encryption processing unit).

[0220] The decryption determination unit 224 and the decryption processing unit 225 are functional units similar to the decryption determination unit 205 (first decryption determination unit) and the decryption processing unit 206 realized by the network interface 104. Note that the decryption processing unit 225 executes the decryption process using the key data stored in the second key storage unit 223.

[0221] The encryption determination unit 226 and the encryption processing unit 227 are functional units similar to the encryption determination unit 209 (first encryption determination unit) and the encryption processing unit 210 (first encryption processing unit) realized by the network interface 104. The encryption processing unit 227 executes encryption processing using key data stored in the second key storage unit 223.

[0222] According to the first modification described above, it is possible to realize a configuration in which the host side performs the decryption and encryption processes for frames belonging to a flow for which the decryption and encryption processes are not performed on the network interface 104 side. Note that the flow for which the decryption and encryption processes are performed on the network interface 104 (or host) side may be predetermined using, for example, a flow identifier.

[0223] Although the processes (decryption and encryption processes) executed on the network interface 104 side have low latency, there may be an upper limit to the number of flows that can be processed by the network interface 104. In such a case, for example, the process for frames belonging to a high-priority flow is executed on the network interface 104 side, and the process for frames belonging to other flows is executed on the host side (i.e., the process related to the encrypted communication is shared), thereby enabling the encrypted communication device 20 to operate efficiently.

[0224] Furthermore, for example, if an error occurs in the decryption or encryption process executed on the network interface 104 side due to a delay in the transfer of key data from the host (second key storage unit 223) to the network interface 104 (first key storage unit 213) (that is, decryption or encryption cannot be performed on the network interface 104 side), the host side may execute the decryption or encryption process using the key data stored in the second key storage unit 223. In this case, the decryption determination unit 224 or the encryption determination unit 226 may be notified by a frame, an interrupt, or the like that the decryption or encryption process should be executed.

[0225] Next, a second modified example will be described with reference to Fig. 27. Fig. 27 is a block diagram showing an example of the functional configuration of an encryption communication device 20 according to the second modified example. In Fig. 27, the same parts as those in Fig. 3 above are given the same reference numerals, and detailed description thereof will be omitted. Here, the parts that differ from Fig. 3 will be mainly described.

[0226] In this embodiment, a configuration has been described in which a frame generated in a host (communication application unit 218) connected to the network interface 104 is transmitted to another encryption communication device 20, or a frame processed in the host (communication application unit 218) is received from another encryption communication device 20, but the encryption communication device 20 of the second variant is configured to forward a frame received from another device (electronic device) to yet another device.

[0227] In this case, the encrypted communication device 20 according to the second modification operates to treat a frame (plaintext frame) received from, for example, the first device (communication application unit) as a transmission frame, encrypt the transmission frame, and transmit the encrypted transmission frame to the second device (communication application unit).Furthermore, the encrypted communication device 20 according to the second modification operates to treat a frame (encrypted frame) received from, for example, the first device (communication application unit) as a reception frame, decrypt the reception frame, and transmit the decrypted reception frame (plaintext frame) to the second device (communication application unit).

[0228] In other words, the encryption communication device 20 according to the second modification can be said to be a cryptographic processing device that decrypts or encrypts frames received from another device when the other device includes a communication application unit. The other device including the communication application unit is connected to the encryption communication device 20 over a network via the communication unit 201.

[0229] Furthermore, when another device includes a communication application unit, the encrypted communication device 20 according to the second modification can also function as a cryptographic processing device that performs both decryption and encryption on frames received from the other device. This can be used, for example, in a configuration in which communication is relayed using different keys. In this case, settings may be made via the communication control unit 219, and the frame header may be rewritten by the transmission control unit 212.

[0230] The encrypted communication apparatus 20 according to the second modification can be realized in the form of a communication device or network apparatus that is used by connecting to an Ethernet port provided in another apparatus that includes a communication application unit, for example.

[0231] In the second modification, the encryption communication device 20 includes a communication setting unit 228 instead of the communication application unit 218 as a functional unit realized by the host.

[0232] The communication setting unit 228 receives settings from the communication application unit 218 of another device via the communication unit 201 , and sets the key management application unit 220 and the communication control unit 219 .

[0233] An example of the processing procedure of the encryption communication device 20 according to the second modification will be described below with reference to the flowchart of FIG.

[0234] First, when a frame is transmitted from another device including a communication application unit to the encryption communication device 20, a receive frame process is executed (step S81). The receive frame process corresponds to the processes of steps S61 to S69 shown in FIG. 21.

[0235] Next, the frame forwarding unit 208 determines whether the destination of the frame for which the receive frame processing was executed in step S81 is the encryption communication device 20 (i.e., the device itself) (step S82). In the determination process, it may be determined that the frame is destined for the device itself if the destination MAC address of the frame matches the MAC address of the device itself. It may also be determined that the frame is destined for the device itself in the case of broadcast or multicast.

[0236] If it is determined that the destination of the frame is not the device itself (NO in step S82), the frame transfer unit 208 outputs (transfers) the frame received from the received frame storage unit 207 directly to the encryption determination unit 209 without going through the internal bus, and transmission frame processing is executed (step S83). Note that the transmission frame processing corresponds to the processing of encrypting the frame that has been subjected to the reception frame processing in step S81 and transferring the encrypted frame to another device. Specifically, in step S83, for example, the processing of steps S46 to S53 shown in FIG. 16 is executed.

[0237] That is, in the second variant, when a frame transmitted from another device is addressed to another device (not to the device itself), an operation is performed that combines the frame reception processing (decryption of the frame) and the frame transmission processing (encryption of the frame) in the above-described present embodiment.

[0238] On the other hand, if it is determined in step S82 that the destination of the frame is its own device (YES in step S82), frame transfer unit 208 writes the frame received from received frame storage unit 207 to main memory 102 via the internal bus and transfers the received frame, and thereafter the same processing as in steps S701 to S705 is performed, and the frame is passed to communication setup unit 228 instead of communication application 218. Communication setup unit 228 accepts the frame (setting from a communication application unit of another device) and performs settings (i.e., communication settings) for communication control unit 219, key management application unit 220, etc. (step S84).

[0239] According to the second modification described above, for example, it is possible to realize a configuration in which the communication application unit is separated into another device (a device other than the encrypted communication device 20).

[0240] Although omitted in FIG. 27, in the second modified example, the number of communication units 201 (number of ports) may be plural, and plural ports may be virtually realized by a VLAN.

[0241] Next, a third modified example will be described with reference to Fig. 29. Fig. 29 shows an example of the internal configuration of the first key storage unit 213 included in the encryption communication device 20 according to the third modified example.

[0242] As shown in FIG. 29, the first key storage unit 213 has a main key storage unit 213a realized by, for example, a DRAM, and a temporary key storage unit 213b realized by, for example, an SRAM.

[0243] In this case, the master key storage unit 213a stores key data in a 128 KiB area provided for each flow, as described in this embodiment. Meanwhile, the temporary key storage unit 213b stores key data used for decryption or encryption processing of one frame (communication transfer unit) (i.e., one decryption or encryption processing) in an area of ​​about 1500 Bytes provided for each flow. As described above, if decryption or encryption is performed using key data of the same size as the communication data (encrypted data or plaintext data), the key data used for the decryption or encryption differs depending on the size of the frame (the encrypted data or plaintext data included in the frame), but the temporary key storage unit 213b stores key data of the same size as the maximum size of the encrypted data or plaintext data (i.e., key data of the maximum size).

[0244] For example, the maximum size of encrypted data is calculated from the maximum size of one frame (communication transfer unit). Specifically, for example, the maximum size of encrypted data corresponds to the data size obtained by subtracting the number of bytes of the L2 and L3 header areas and encryption information fields from queueMaxSDU, which is the maximum size of a service unit defined for each queue or MTU (Maximum Transmission Unit). Furthermore, when key data is used to generate the above-mentioned authentication data, in addition to key data of the same size as the above-mentioned maximum size of encrypted data, the key data used to generate the authentication data may also be written to temporary key storage unit 213b.

[0245] The first key storage unit 213 further includes a temporary key storage control unit 213c. The temporary key storage control unit 213c executes a process of reading key data from the master key storage unit 213a for each flow in accordance with updates to the read position in the key data management unit 214 (second key management data) and writing (storing) the key data in the temporary key storage unit 213b. That is, the key data to be used for the next frame transmission is read in advance and cached.

[0246] In addition, since the key data (key data of the maximum size) to be written to the temporary key memory unit 213b needs to be read from the main key memory unit 213a, the key data management unit 214 may have an interface for setting the size of the key data (maximum size of encrypted data).

[0247] In the third variant described above, by obtaining key data from the temporary key storage unit 213b implemented by SRAM, which can be accessed with less latency than DRAM, rather than from the main key storage unit 213a implemented by DRAM, and using the key data for decryption or encryption, it is possible to speed up (reduce latency) the processing related to decryption or encryption in the encryption communication device 20 (network interface 104).

[0248] (Second embodiment) Next, a second embodiment will be described. In the first embodiment described above, a configuration in which key data is transferred from a host (CPU and main memory) to a network interface is described, but this embodiment differs from the first embodiment in that key data is stored in storage and is directly transferred from the storage to a network interface.

[0249] The outline of the communication system and the configuration of the encrypted communication device in this embodiment are the same as those in the first embodiment, and therefore will be described with reference to FIGS. 1 and 2 as appropriate.

[0250] 30 is a block diagram showing an example of the functional configuration of the encryption communication device 20 according to this embodiment. In the first embodiment described above, the second key storage unit 223 is a functional unit implemented by the host, and the key data transfer unit 215 is a functional unit implemented by the network interface 104. However, in this embodiment, the second key storage unit 223 and the key data transfer unit 215 are functional units implemented by the storage 103. In this embodiment, the storage 103 includes an SSD (Solid State Drive), and the storage area for the second key storage unit 223 is secured within the SSD. Furthermore, the key data transfer unit 215 is implemented by a DMA controller or the like provided in the SSD (storage).

[0251] Furthermore, in the first embodiment described above, the priority arbitration unit 217 was described as a functional unit implemented by the network interface 104, but in this embodiment, the priority arbitration unit 217 is a functional unit implemented by the host. Furthermore, in this embodiment, a file management unit 229 is further included as a functional unit implemented by the host. Note that in this embodiment, it is not necessary to provide a second key storage unit 223 as a functional unit implemented by the host.

[0252] File management unit 229 is realized by a function such as a file system that runs on the OS, and manages the storage area of ​​second key storage unit 223 and provides an interface for writing and reading data using a file name. According to such file management unit 229, the key data acquired by key acquisition unit 221 is managed as a file.

[0253] The key management application unit 220 may manage the location of the key data stored in the second key storage unit 223, for example, by using a file name. A QKD key identifier may be used as the file name, for example. When an instruction to acquire key data is given by the key management application unit 220, the key acquisition unit 221 acquires the key data from the QKD device 10 and stores the key data in a specified file. The file in which the key data is stored is written to the second key storage unit 223 by the file management unit 229.

[0254] Furthermore, the key data receiving unit 216 in this embodiment has a setting interface and is equipped with a function of deleting (removing) data from the first data to the valid data offset for each flow in the key data transferred from the storage 103 (second key memory unit 223) and extracting data of the valid data length from which the data has been deleted. In this embodiment, the key data receiving unit 216 receives transfer of key data via memory-mapped I / O.

[0255] The operation of the encryption communication device 20 according to this embodiment will be described below. As in the first embodiment, the encryption communication device 20 according to this embodiment executes a sending side setting process, a receiving side setting process, a key data transfer process, a frame sending process, and a frame receiving process. However, since the processes other than the key data transfer process are the same as those in the first embodiment, detailed description thereof will be omitted here.

[0256] An example of the processing procedure for key data transfer processing will be described with reference to the flowchart of Fig. 31. Here, differences from the above-mentioned Fig. 13 will be mainly described.

[0257] First, steps S91 to S94 are executed, which correspond to steps S21 to S24 shown in Fig. 13. Note that the key data in this embodiment is stored in the second key storage unit 223 as a file.

[0258] Next, the key management application unit 220 instructs the key data transfer unit 215 to transfer the key data via the key transfer control unit 222 (step S95).

[0259] In this embodiment, the key management application unit 220 manages the key data stored in the second key storage unit 223 using the first key management data shown in Fig. 32. The first key management data in this embodiment differs from the first key management data shown in Fig. 5 in that the addresses are file names. The key management application unit 220 references this first key management data to specify the file name of the file in which the key data of the flow (target flow) identified in step S91 is stored, the offset from which the transfer will start (the position from the beginning of the file), and the length of the key data to be transferred.

[0260] Key transfer control unit 222 acquires a position in second key storage unit 223 based on an instruction from key management application unit 220 (step S96). Note that when a file name is given, file management unit 229 responds with the extents (information on consecutive data blocks expressed as a pair of a start position and a length) that make up the file to which that file name is assigned. Therefore, key transfer control unit 222 may acquire the positions of one or more data blocks in second key storage unit 223 from the offset and key data length instructed by key management application unit 220.

[0261] In this case, data transfer from a storage 103 (second key memory unit 223) such as an SSD is performed in sector units rather than byte units, so the key transfer control unit 222 calculates the start position for reading in sector units and the length of the data read in sector units from that start position, as well as the start position (offset) of the valid data of the data read in sector units and the valid data length from that start position (i.e., the data length of the key data to be transferred) based on the extent information and first key management data (transferred data size) that make up the above-mentioned file.

[0262] Next, the key transfer control unit 222 sets the start offset of the valid data and the length of the valid data from the start offset (i.e., the valid data length) in the key data reception unit 216 in order to delete excess data at the beginning and end when the key data is transferred in sector units (i.e., to obtain valid data from the key data transferred in sector units) (step S97).

[0263] Here, Fig. 33 shows an example of the interface of the key data reception unit 216. In the example shown in Fig. 33, the interface of the key data reception unit 216 is provided with a setting interface for setting the start offset of valid data, the valid data length, and the data write destination address of the first key storage unit 213 for each channel (each key transfer channel) used for transferring key data. The interface of the key data reception unit 216 also has an interface for writing data to the data write area of ​​each channel.

[0264] When the key data receiving unit 216 writes data from the key data transfer unit 215 to the data write area (address indicating the area) of each channel, it can output data in byte units with unnecessary parts deleted based on the valid data start offset and valid data length set for the channel.

[0265] Although the description has been given assuming that a data write destination address in the first key storage unit 213 is set for each channel, a flow identifier may be set instead of the data write destination address. In this case, the data write destination address may be calculated using the flow identifier when key data is written to the first key storage unit 213.

[0266] When the processing of step S97 is executed, the key transfer control unit 222 sets the descriptor and instructs the key data transfer unit 215 to transfer the key data, and the key data transfer unit 215 transfers the key data from the second key memory unit 223 (i.e., storage 103) to the first key memory unit 213 (i.e., network interface 104) (step S98).

[0267] Here, in the case of a configuration using the key data transfer unit 215 of the storage 103 as in this embodiment, the descriptor entries that make up the key transfer descriptor ring are different from those in the first embodiment described above.

[0268] Fig. 34 shows an example of a descriptor entry in this embodiment. As shown in Fig. 34, the descriptor entry includes a key data sector position, the number of key data sectors, a key data transfer destination address, and a status. The key data sector position indicates the sector position of the key data stored in the second key storage unit 223 (key data transferred from the second key storage unit 223). The number of key data sectors indicates the number of sectors of the key data stored in the second key storage unit 223. The key data transfer destination address indicates the starting address when the key data transfer unit 215 writes key data, and corresponds to the starting address of the data write area prepared for each channel in the setting interface of the key data reception unit 216. The status is as described in the first embodiment above.

[0269] The key transfer control unit 222 sets the sector-by-sector read start position and the length of the data read from the sector-by-sector start position, obtained by the above-mentioned processing, in the key data sector position and key data of the descriptor entry, respectively. It also specifies the start address of the data write area corresponding to the channel to be used as the key data transfer destination address. It then instructs the key data transfer unit 215 to perform the descriptor processing (key data transfer processing) set for the descriptor entry, using the channel number (number assigned to the channel) and the descriptor number (number assigned to the descriptor).

[0270] In this case, when the priority arbitration unit 217 permits transmission on the channel instructed to perform transfer, the key data transfer unit 215 reads key data in sector units from the second key memory unit 223 based on the information on the key data sector position and the number of key data sectors in the descriptor, and writes the key data to the data write area set in (the setting interface of) the key data reception unit 216 specified by the key data transfer destination address in the descriptor entry.

[0271] The key data reception unit 216 deletes the beginning and end of the data written in sector units for each channel (i.e., unnecessary data) using the valid data start offset and valid data length set for each channel. The key data reception unit 216 writes the data after the unnecessary data has been deleted (i.e., key data for each channel) in byte units to the specified data write destination address of the first key storage unit 213 sequentially.

[0272] When the process of step S98 is completed, the processes of steps S99 to S103, which correspond to the processes of steps S27 to S31 shown in FIG. 13, are executed.

[0273] As described above, in this embodiment, key data is transferred from the storage 103 (storage device) constituting the encrypted communication device 20 to the network interface 104. Note that, like the first embodiment, the transfer of key data in this embodiment is performed by DMA without going through processing by the CPU 102.

[0274] In addition, in this embodiment, since data is read from the second key memory unit 223 (storage 103) on a sector-by-sector basis, the first key memory unit 213 stores key data extracted from the data transferred from the storage 103 on a sector-by-sector basis (i.e., key data obtained by deleting unnecessary data from the sector-by-sector data).

[0275] Here, in the configuration in which key data is stored in storage 103 described in the first embodiment, the host obtains the key data from storage 103, and the key data is transferred from the host to network interface 104. In this configuration, although a large amount of key data can be stored in storage 103, the key data is transferred in the order of storage 103, host (CPU 101 and main memory 102), and network interface 104, which is inefficient.

[0276] In contrast to this, in this embodiment, the above-described configuration allows the key data stored in the storage 103 to be transferred directly to the network interface 104, thereby realizing efficient transfer of key data.

[0277] Furthermore, in this embodiment, there is no need to store key data on the host side (main memory 102), so the capacity of the main memory 102 can be reduced.

[0278] In the first embodiment described above, the first to third modified examples have been described, but at least some of the first to third modified examples described in the first embodiment may be applied to the second embodiment.

[0279] According to at least one of the above-described embodiments, it is possible to provide a communication control device, a communication device, a communication system, a method, and a program that can achieve low-latency communication when a cryptographic communication method that switches keys sequentially is used.

[0280] In the above-described embodiments, the flow identifier 203 (stream identifier) ​​is provided as a receiving-side network interface (a function of the receiving-side encryption communication device 20b). However, a flow identifier may be provided as a transmitting-side network interface. In this case, similar to the flow identifier 203 of the receiving-side network interface, the flow identifier of the transmitting-side network interface may also be set in advance from the communication application unit 218. In this case, the flow identifier obtained by the flow identifier 203 is set as the flow identifier of the attached information.

[0281] Furthermore, in the above-described embodiments, it has been described that a key transfer request is issued when the transferable amount of key data is equal to or greater than a certain value (e.g., 64 KiB), but the key transfer request may also be issued, for example, when the remaining amount of key data stored in first key storage unit 213 is equal to or less than a certain value. In other words, each embodiment may be configured to request the transfer of key data based on the amount of key data stored in first key storage unit 213.

[0282] Furthermore, in the above-described embodiments, the one-time pad has been mainly used as the cryptographic communication method (encryption method), but the Advanced Encryption Standard (AES) or the like may be used instead of the one-time pad. That is, the above-described embodiments may be applied to a cryptographic communication method in which the key is changed (switched) every certain number of times or every certain time.

[0283] 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 embodiments can be implemented 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, as well as within the scope of the invention described in the claims and their equivalents. [Explanation of symbols]

[0284] 1...communication system, 2...quantum communication channel, 3, 4...classical communication channel, 10, 10a, 10b...QKD device, 11a...key generation unit, 11b...key reception unit, 12a...key transmission unit, 12b...communication unit, 13a...communication unit, 13b...key distillation unit, 14a...key distillation unit, 14b...key provision unit, 15a...key provision unit, 20, 20a, 20b...encryption communication device, 21a...communication application unit, 21b...communication unit, 22a...encryption processing unit, 22b...decryption processing unit, 23a...communication unit, 23b...communication application unit , 101...CPU, 102...main memory, 103...storage, 104...network interface (communication control device), 201...communication unit, 202...priority identification unit, 203...flow identification unit, 204...reception control unit, 205...decryption determination unit, 206...decryption processing unit (first processing unit), 206a...key data selection unit, 206b...arithmetic unit, 206c...read position update unit, 206d...encryption information removal unit, 207...received frame storage unit, 208...frame forwarding unit , 208a...transmission frame transfer unit, 208b...reception frame transfer unit, 209...encryption determination unit, 210...encryption processing unit (first processing unit), 210a...key data selection unit, 210b...calculation unit, 210c...read position update unit, 210d...encryption information addition unit, 211...transmission frame storage unit, 212...transmission control unit, 213...first key storage unit (first storage unit), 213a...main key storage unit (first storage unit), 213b...temporary key storage unit (second storage unit), 213c...temporary key storage unit storage control unit, 214...key data management unit (request unit), 215...key data transfer unit, 216...key data reception unit, 217...priority arbitration unit, 218...communication application unit, 219...communication control unit, 220...key management application unit, 221...key acquisition unit, 222...key transfer control unit, 223...second key storage unit, 224...decryption determination unit, 225...decryption processing unit (second processing unit), 226...encryption determination unit, 227...encryption processing unit (second processing unit), 228...communication setting unit, 229...file management unit.

Claims

1. In a communication control device provided in a first communication device, an acquisition unit that acquires data transmitted from the first communication device to the second communication device or data transmitted from the second communication device to the first communication device via a network; a first processing unit that, when the acquired data belongs to a flow to be encrypted or decrypted, executes encryption processing or decryption processing on the acquired data using key data; a request unit that requests transfer of key data for each flow via an internal bus of the first communication device; a first storage unit that stores the key data transferred in response to the request; A communication control device comprising:

2. The communication control device according to claim 1 , wherein the internal bus includes a PCIe (PCI Express) bus.

3. The communication control device according to claim 2 , wherein the key data is transferred from a host or storage provided in the first communication device.

4. 4. The communication control device according to claim 3, wherein the key data is transferred by DMA (Direct Memory Access).

5. 5. The communication control device according to claim 4, wherein the first storage unit stores key data extracted from data transferred from the storage in sector units.

6. 2. The communication control device according to claim 1, wherein the request unit requests the transfer of the key data based on key management data that manages the key data stored in the first storage unit.

7. Further comprising a second storage unit that can be accessed faster than the first storage unit, the second storage unit stores key data to be used for executing one encryption process or one decryption process among the key data stored in the first storage unit; The first processing unit executes encryption processing or decryption processing using the key data stored in the second storage unit. The communication control device according to claim 1.

8. 2. The communication control device according to claim 1, wherein the transfer of the key data is controlled based on a priority assigned to a flow to which the data belongs.

9. 2. The communication control device according to claim 1, wherein the host constituting the first communication device includes a second processing unit that performs encryption or decryption processing on data that is not encrypted or decrypted by the first processing unit.

10. 2. The communication control device according to claim 1, wherein the request unit requests the transfer of the key data based on the amount of the key data stored in the first storage unit.

11. 2. The communication control device according to claim 1, wherein the requesting unit requests transfer of key data longer than key data used to execute one encryption or decryption process.

12. A communication device comprising a host and a communication control device connected to the host via an internal bus, The communication control device an acquisition unit that acquires data transmitted to another communication device via a network or data transmitted from the other communication device; a first processing unit that, when the acquired data belongs to a flow to be encrypted or decrypted, executes encryption processing or decryption processing on the acquired data using key data; a request unit that requests transfer of key data for each flow via the internal bus; a first storage unit that stores the key data transferred from the host in response to the request; Contains Communication equipment.

13. A communication system including a quantum key distribution device that generates key data and performs quantum key distribution for the key data, and a communication device that includes a host and a communication control device connected to the host via an internal bus, The communication control device an acquisition unit that acquires data transmitted to another communication device via a network or data transmitted from the other communication device; a first processing unit that, when the acquired data belongs to a flow to be encrypted or decrypted, executes encryption processing or decryption processing on the data using the key data; a request unit that requests transfer of key data for each flow via the internal bus; a first storage unit that stores the key data transferred from the host in response to the request; Contains Communication system.

14. A method executed by a communication control device provided in a first communication device, acquiring data transmitted from the first communication device to the second communication device or data transmitted from the second communication device to the first communication device via a network; If the acquired data belongs to a flow to be encrypted or decrypted, encrypting or decrypting the data using key data; requesting transfer of key data for each flow via an internal bus of the first communication device; storing the key data transferred in response to the request in a first storage unit; A method comprising:

15. A program executed by a computer of a communication control device provided in a first communication device, The computer, acquiring data transmitted from the first communication device to the second communication device or data transmitted from the second communication device to the first communication device via a network; If the acquired data belongs to a flow to be encrypted or decrypted, encrypting or decrypting the data using key data; requesting transfer of key data for each flow via an internal bus of the first communication device; storing the key data transferred in response to the request in a first storage unit; A program that executes the following.

Images