Key management device, quantum cryptography communication system and program
The key management device addresses the limitation of QKD systems by providing both encryption keys and random numbers, thereby enhancing the functionality of quantum cryptographic communication systems.
Patent Information
- Application Number
- JP2022045276
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-03-22
- Publication Date
- 2025-05-19
- Estimated Expiration
- 2042-03-22
AI Technical Summary
Existing quantum key distribution (QKD) systems are unable to provide random numbers as required, limiting their functionality in cryptographic data communication.
A key management device is introduced, comprising a determination unit, a generation unit, and a provision unit, which determines the type of requested data, generates a provision message including cryptographic keys and random numbers, and provides this message to applications via a communication network.
The key management device enables the provision of both encryption keys shared by QKD and random numbers according to application requests, enhancing the functionality of quantum cryptographic communication systems.
Smart Images

Figure 0007679330000001 
Figure 0007679330000002 
Figure 0007679330000003
Abstract
Description
Technical Field
[0001] Embodiments of the present invention relate to a key management device, a quantum cryptographic communication system, and a program.
Background Art
[0002] Quantum Key Distribution (QKD) technology for securely sharing encryption keys by using single photons continuously transmitted between a transmitting node and a receiving node connected by an optical fiber has been conventionally known. The encryption keys shared by the quantum key distribution technology are guaranteed not to have been eavesdropped on based on the principles of quantum mechanics. Also, information theory guarantees that encrypted data communication using a one-time pad (OTP) with this encryption key cannot be decoded by any eavesdropper with any knowledge.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Patent Document 2
Non-Patent Documents
[0004]
Non-Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0005] However, in the prior art, not only the cryptographic key shared by QKD but also random numbers could not be provided as required.
Means for Solving the Problems
[0006] The key management device of the embodiment includes a determination unit, a generation unit, and a provision unit. The determination unit determines the type of requested data requested by a request message transmitted from an application that performs cryptographic data communication. The generation unit generates a provision message including at least one of a cryptographic key shared by QKD (Quantum Key Distribution) and random numbers via a communication network according to the type of the requested data. The provision unit provides the provision message to the application.
Brief Description of the Drawings
[0007]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10A
Figure 10B
Figure 10C
Figure 10D
Figure 11A
Figure 11B
Figure 11C
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
DETAILED DESCRIPTION OF THE INVENTION
[0008] Embodiments of a key management device, a quantum cryptographic communication system, and a program will be described in detail below with reference to the accompanying drawings.
[0009] In a QKD network, an API (Application Programming Interface) technology for providing encryption keys to applications has been standardized, and this API technology has started to be used. Also, in a quantum cryptographic communication system, there are cases where an application wants to use not only an encryption key that is a random number shared with other nodes but also a random number (unique random number) independent of other nodes. Alternatively, when performing encrypted communication using a symmetric key encryption method such as the AES (Advanced Encryption Standard) cipher, there are cases where, in addition to the encryption key, another random number to be used as an IV (initialization vector) is to be obtained simultaneously.
[0010] In the following embodiments, a key management device, a quantum cryptographic communication system, and a program that enable an API to provide not only an encryption key shared by QKD but also a random number according to a request will be described.
[0011] (First Embodiment) First, the basic configuration of a quantum cryptographic communication system will be described. The transmission node and the reception node are collectively referred to as nodes. The nodes in the embodiment are, for example, called TN (Trusted Node). Also, a function of performing encrypted data communication using a shared encryption key is called an application (hereinafter referred to as "app") separately from the node.
[0012] [Example of the basic configuration of a quantum cryptographic communication system] FIG. 1 is a diagram showing an example of the basic configuration of the quantum cryptographic communication system according to the first embodiment. Node 10a includes KM20a and QKD module 30a. KM (Key Manager) 20a is a key management device that manages encryption keys. QKD module 30a shares encryption keys by quantum key distribution (QKD).
[0013] Note that KM20a and the QKD module 30a may be implemented as a single device / system, or may be configured as separate devices / systems. For example, the node 10a may not include the QKD module 30a. In this case, the KM20a of the node 10a and the QKD module 30a implemented as an external device of the node 10a are connected by a link. The description of the node 10b is omitted because it is the same as that of the node 10a.
[0014] In the example of FIG. 1, the encryption keys shared by the QKD link 130 between the nodes 10a and 10b are provided to the apps 40a and 40b, respectively. The apps 40a and 40b encrypt data using the encryption keys obtained from the nodes 10a and 10b and perform encrypted data communication. However, the method of sharing encryption keys using QKD technology has a limitation on the distance over which encryption keys can be shared due to the use of single photons as the medium.
[0015] [Example of Quantum Key Distribution Communication System] FIG. 2 is a diagram showing an example of the device configuration of the quantum key distribution communication system 100 according to the first embodiment. The node 10a includes a KM20a and a QKD module 30a. The node 10a is connected to the app 40a. The node 10b includes a KM20b and QKD modules 30b-1 to 30b-2. Since the node 10b is connected to both the nodes 10a and 10c, it includes two QKD modules 30b. The node 10c includes a KM20c and a QKD module 30c. The node 10c is connected to the app 40c.
[0016] Hereinafter, when the nodes 10a to 10c are not distinguished, they are simply referred to as the node 10. Similarly, when the KM20a to 20c are not distinguished, they are simply referred to as the KM20. Similarly, when the QKD modules 30a to 30c are not distinguished, they are simply referred to as the QKD module 30. Similarly, when the apps 40a and 40c are not distinguished, they are simply referred to as the app 40.
[0017] In the example of FIG. 2, a key sharing network (QKD network) 120 and a QKD link 130 are configured by a communication network in which nodes 10a to 10c having the functions of a transmission node and a reception node are connected to each other by optical fiber links. Note that the key sharing network 120 may use a link different from the optical fiber of the QKD link 130 that performs key distribution by QKD, and the number of links is not limited. That is, the key sharing network 120 and the QKD link 130 may be independently configured by different optical fibers. Apps 40a and 40c are accommodated in the encrypted data communication network 110.
[0018] A case of performing encrypted data communication between app 40a and app 40c will be described.
[0019] The QKD module 30 of each node 10 shares the encryption key shared by QKD with the QKD 30 module of the adjacent node 10 connected by an optical fiber link as a local key. KM20a (20c) provides a common encryption key (hereinafter referred to as "global key") to app 40a (40c). Thereafter, app 40a (40c) encrypts data using the global key provided by KM20a (20c) and performs encrypted data communication.
[0020] Here, a specific example of a method for sharing a common global key in apps 40a and 40c will be shown. Note that the sharing method shown here is an example, and any method for sharing the global key in the key sharing network 120 may be used as long as the common global key can be shared.
[0021] Node 10a generates a global key different from the local key from separate random information or the like, independent of QKD. The KM20a of node 10a encrypts the global key with the local key shared between the QKD modules 30a and 30b-1, and transfers the encrypted global key to the KM20b of the adjacent node 10b. Next, the KM20b of the adjacent node 10b encrypts the global key with the local key shared between the QKD modules 30b-2 and 30c, and transfers the encrypted global key to the KM20c of the adjacent node 10c.
[0022] In this way, by repeating the process of encrypting the global key with the local key and transferring the global key, node 10 can share the global key with any node 10 on the key sharing network 120. At this time, the global key is transferred on the link in an encrypted state by the local key shared by QKD. Therefore, assuming the security of node 10 itself, it can be said that the security of the global key is guaranteed in the same way as the local key.
[0023] [Example of Global Key Provisioning Process] FIG. 3 is a sequence diagram showing an example of the global key provisioning process of the first embodiment. In the example of FIG. 3, an example of a sequence in which the applications 40a and 40c perform encrypted data communication will be described. The application 40a is connected to the node 10a on the key sharing network 120. The application 40c is connected to the node 10c on the key sharing network 120.
[0024] First, local keys are shared between nodes 10a and 10b by QKD (step S1). Next, local keys are shared between nodes 10b and 10c by QKD (step S2).
[0025] Next, the application 40a sends a global key request (global key request message) to the node 10a (step S3). The global key request indicates a request for a global key to be used for encrypted data communication with the application 40c.
[0026] Next, the node 10a identifies the node 10c connected to the application 40c that communicates with the application 40a from the information on the application name (application 40c) included in, for example, the global key request (step S4). Note that the node 10a may identify the node 10c connected to the application 40c by referring to data called a connection information directory.
[0027] Next, the node 10a starts global key sharing control with the node 10c (step S5). Specifically, the node 10a transmits a notification indicating a request for global key sharing processing to the node 10c.
[0028] The operation of the global key sharing process is as described above. For example, the node 10a uses a random number generated using a random number generator or the like as the global key (step S6), encrypts the global key with the local key shared with the node 10b (step S7), and transmits the encrypted global key to the node 10b. The node 10b decrypts the encrypted global key with the same local key as the local key of the node 10a to extract the global key. Next, the node 10b encrypts the global key with the local key shared with the node 10c (step S8), and transmits the encrypted global key to the node 10c. The node 10c decrypts the encrypted global key with the same local key as the local key used for encryption by the node 10b to extract the global key (step S9). Next, the node 10c stores the decrypted global key in a storage or the like (step S10). Next, the node 10c transmits a global key storage notification indicating that the global key has been stored to the node 10a (step S11).
[0029] Note that it is also possible to use a global key that has been shared in advance between the node 10a and the node 10c without performing the global key sharing operation in steps S5 to S11.
[0030] Next, node 10a sends a global key providing message containing the global key shared with node 10c to app 40a (step S12). The global key providing message includes the global key shared by nodes 10a and 10c and the key ID assigned to the global key.
[0031] Next, app 40a notifies app 40c of the key ID of the global key used for encrypted communication (step S13). Note that this key ID notification may be made prior to encrypted communication between apps 40a and 40c, or app 40a may notify it together with the encrypted data encrypted with the global key.
[0032] Next, when node 10c receives a global key request (global key request message) from app 40c (step S14), it provides the global key stored in step S10 to app 40c (step S15).
[0033] Note that app 40c generates a global key request message when sending encrypted data to app 40a or decrypting encrypted data received from app 40a. The global key request message includes the key ID of the global key requested by app 40c. Node 10c returns the global key corresponding to the key ID included in the global key request message among the global keys shared with node 10a to app 40c (global key providing message).
[0034] Apps 40a and 40c perform encrypted data communication using the common encryption key (global key) obtained through the above flow (step S16).
[0035] FIG. 4 is a diagram for explaining an example of the key providing interface of the first embodiment. In the example of FIG. 4, a random number generation module 50a for generating a random number used for the global key is further connected to node 10a (10c).
[0036] The node 10a in FIG. 4 can be used as a mechanism for sharing an encryption key generated by another system and any secret information such as a private key in a digital certificate - public key system. Also, since the node 10a is equipped with not only the KM20a but also the QKD module 30a, the random number generation function of the random number generation module 50a may be used for key sharing in QKD. Note that the random number generation function may be in a device separate from the node 10a (for example, a random number generation management server device, etc.) like the random number generation module 50a shown in FIG. 4, or may be built into the node 10a.
[0037] In FIG. 4, the app 40a on the side that starts the encrypted communication session is called the master, and the app 40c on the side that accepts the encrypted communication session is called the slave. The request messages and provided messages exchanged between the app 40 and the node 10 are realized, for example, by calling a Web API and its response.
[0038] [Example of Key Provisioning API] FIG. 5 is a diagram showing an example of the key provisioning API of the first embodiment.
[0039] The first API is a status check API for the app 40 to inquire about the state of the node 10 or the quantum encrypted communication system.
[0040] The second API is a key acquisition API for the master app 40a to acquire an encryption key from the node 10a. The master app 40a specifies, for example, the number of encryption keys in the key acquisition API. When the key acquisition API is called from the app 40a, the node 10a responds to the master app 40a with the encryption key and the key ID of the encryption key.
[0041] The third API is a key acquisition API for the slave app 40c to acquire an encryption key from the node 10c. The slave app 40c specifies, for example, the key ID of the encryption key in the key acquisition API. When the key acquisition API is called from the app 40c, the node 10c responds to the slave app 40c with the encryption key and the key ID of the encryption key.
[0042] In addition, in the responses of the second and third APIs, when the encryption key and key ID are defined in JSON format, an example of the response data format is as shown in FIG. 6.
[0043] FIG. 6 is a diagram showing an example of the response data format of the encryption key and key ID according to the first embodiment. In the example of FIG. 6, it shows the case of the response data format in which the data of Key ID indicating the key ID and the data of Key indicating the encryption key are associated.
[0044] There are cases where the application 40 wants to use high-quality random number data during encrypted communication (for example, the initial vector (IV) for encrypted communication and the random numbers for secret distributed storage of data, etc.). In the first embodiment, assuming application to such use cases, the node 10 provides, by means of the key providing API, in combination with the encryption key, the random numbers generated by the random number generation module 50. Also, in the KM20 that provides the encryption key and random number data, the encryption key and random numbers are integrally and efficiently generated, held, and managed.
[0045] [Example of functional configuration] FIG. 7 is a diagram showing an example of the functional configuration of the KM20 according to the first embodiment. The KM20 according to the first embodiment includes a providing unit 1, a communication unit 2, a random number acquisition unit 3, a key acquisition unit 4, a determination unit 5, and a generation unit 6.
[0046] The providing unit 1 provides the data generated by the generation unit 6 to the application 40 in response to a request message (API call) from the application 40.
[0047] The communication unit 2 communicates with other devices. For example, the communication unit 2 performs communication for sharing keys and random numbers, communication for notifying the unusability of keys, or communication for instructing the deletion of keys, etc., to another KM20.
[0048] The random number acquisition unit 3 acquires random numbers from the random number generation module 50 or the like.
[0049] The key acquisition unit 4 acquires the key generated by QKD from the QKD module 30.
[0050] The determination unit 5 determines the provided data (at least one of a key and a random number) according to a request message from the application 40. For example, when the determination unit 5 receives a request message (API call) that designates at least one of a cryptographic key and a random number from the application 40, it determines the size and number of the required cryptographic key, and the size and number of the required random number. Also, for example, when the determination unit 5 receives a request message (API call) that designates at least one of a cryptographic method, a communication destination, and a data size, it determines the cryptographic key of the required size and number, the size and number of the required cryptographic key, and the size and number of the required random number according to the requested cryptographic method, communication destination, and data size.
[0051] The generation unit 6 generates the data (at least one of a key and a random number) to be provided to the application 40. The generation unit 6 generates data (for example, JSON data) to be returned in the same message format as a provided message (API response) based on the determination by the determination unit 5. The provided message includes at least one of the random number acquired from the random number acquisition unit 3 and the cryptographic key acquired from the key acquisition unit 4.
[0052] [Example of providing a random number] FIG. 8 is a diagram showing an example of providing random numbers in the first embodiment. As shown in FIG. 8, the node 10 in the first embodiment provides a random number instead of a cryptographic key, or provides both a cryptographic key and a random number, in an API response (provision message) in response to an API call (request message) from the application 40a to the node 10a. That is, the node 10 in the first embodiment provides a random number simultaneously with the cryptographic key to the application 40 connected to the node 10, or provides the random number in the same message format as the provision of the cryptographic key. Thereby, for example, simultaneously with the provision of the key, an IV (random number) of an appropriate size for use in encrypted communication can be provided in a single API call. Also, for example, when simultaneously performing data protection by secret sharing and encrypted communication using a cryptographic key, they can be provided in a single API call.
[0053] [Example of API Call and Response] FIG. 9 is a diagram showing an example of an API call and response in the first embodiment. FIG. 9 shows an example of the relationship (combination) between an API call (request) and an API response (response).
[0054] Item No. 1 is a case where only the cryptographic key is received from the node 10. A request for the cryptographic key is made as an API call, and the cryptographic key is responded as an API response.
[0055] Item No. 2 is a case where not only the cryptographic key but also a random number is received from the node 10. A request for the cryptographic key is made as an API call, and in the API response, both the cryptographic key and a random number are responded.
[0056] Item No. 3 is a case where only the random number is received from the node 10. A request for the random number is made as an API call, and the random number is responded as an API response.
[0057] Item No. 4 is a case where not only the random number but also the cryptographic key is received from the node 10. A request for the random number is made as an API call, and in the API response, both the random number and the cryptographic key are responded.
[0058] Item number 5 is a case where the node 10 receives a random number and an encryption key. A request for the encryption key and the random number is made as an API call, and the encryption key and the random number are responded as an API response.
[0059] Item number 6 is a case where the node 10 receives a random number and an encryption key. A communication method or a destination is specified as an API call, and the encryption key and the random number are responded as an API response. For item number 6, different types, sizes, and numbers of encryption keys and random numbers may be provided according to the specified destination, for example.
[0060] Among the APIs of item numbers 1 to 6, which API operation is enabled is determined by the setting of the node 10, for example. For example, for item numbers 1 and 2, both API calls are requests for an encryption key, but whether the encryption key is responded as an API response or both the encryption key and the random number are responded is determined by the setting of the node 10.
[0061] Also, the encryption key included in the API response may be arbitrary according to the application. For example, the encryption key included in the API response may be arbitrary, such as the above-mentioned local key and global key.
[0062] [Specific examples of API calls] Figures 10A to 10D are diagrams showing specific examples of API calls (requests) of the first embodiment. The request message from the application 40 is realized by the APIs of Figures 10A to 10D, for example. {KME_hostname} included in the url of the POST method indicates the hostname (IP address) of the node 10. In Figures 10A to 10D, the parameters are specified in the request body of the POST method, but they may be specified by the GET method.
[0063] Figure 10A shows a case where a random number is specified in an API call. If only a random number is required, there is no need to specify the communication destination as a parameter. For example, in the example of Figure 10A, in the request body of the POST parameters, the type of data requested (rng indicating a random number in the example of Figure 10A), the number (3 in the example of Figure 10A), and the size (1024 in the example of Figure 10A) are specified as parameters.
[0064] Note that the type in Figure 10A is a parameter that specifies at least one of a cryptographic key and a random number as the type of data requested from the application 40. The number is a parameter that specifies the number of requested data. The size is a parameter that specifies the size of the requested data. The generation unit 6 generates a provision message including the requested data of the size and number specified by the request message by the API.
[0065] Figure 10B shows a case where a call is made by specifying a key and a random number. In the API of Figure 10B, since a key is obtained, the communication destination is specified in the (SAE_ID). For example, an ID for identifying the communication destination application 40 is specified in the SAE_ID. For example, in the example of Figure 10B, in the request body of the POST parameters, the type, number, and size of the requested data are specified as parameters. For example, the type key included in the parameters in the second line of the request body of the POST parameters in Figure 10B indicates a cryptographic key, the number indicates the number of the cryptographic keys, and the size indicates the size of the cryptographic keys.
[0066] Figure 10C makes a call by specifying a key and a random number in the same API call as Figure 10B. For example, in the request body of the POST parameters, the random number size is not specified. For example, when requesting a key in the request body of the POST parameters, the number and size parameters are specified, and when requesting a random number, the number and size are not specified. In this case, for the number and size of the random number, KM20 of the node 10 determines based on the settings of KM20 and the like.
[0067] Figure 10D shows a case where a communication method is specified. The API in Figure 10D is called with the same API call (the same URL specification) as in Figure 10B. However, for example, in the request body of the POST parameter, the number and size of keys and the number and size of random numbers are not specified, but the encryption method to be used (default AES in the example of Figure 10D) is specified. In this case, regarding the number and size of random numbers, KM20 of node 10 determines them based on the encryption method to be used.
[0068] Note that the request message by the API call in Figure 10D may include at least one of a method parameter for specifying the encryption method used in app 40 and a destination parameter for specifying the communication destination of app 40. When the method parameter is included in the request message, the generation unit 6 generates a provided message including at least one of an encryption key and a random number according to the method parameter. Also, when the destination parameter is included in the request message, the generation unit 6 generates a provided message including at least one of an encryption key and a random number according to the destination parameter.
[0069] Furthermore, the request message by the API call in Figure 10D may further include a size parameter for specifying the data size. In this case, the generation unit 6 generates a provided message including at least one of an encryption key with the size specified by the size parameter and a random number with the size specified by the size parameter.
[0070] In addition, the request message by the API call may include a size parameter for specifying the data size of the transmission data. When the size parameter is included in the request message, the generation unit 6 generates a provided message including at least one of an encryption key used for encrypting the data with the size specified by the size parameter and a random number used for encrypting the data with the size specified by the size parameter.
[0071] Specifically, when only the size parameter is specified by an API call, the generation unit 6 generates a provision message including an encryption key used for encrypting data of the size specified by the size parameter and a random number used for encrypting data of that data size. The random number used for encryption processing includes, for example, a random number used as an IV and a random number necessary for protecting data of that size by secret sharing.
[0072] [Specific Example of API Response] FIGS. 11A to 11C are diagrams showing specific examples of the API response (response) of the first embodiment. In FIGS. 11A to 11C, an example of returning a response in JSON format is shown.
[0073] FIG. 11A shows a case where a random number is returned. rng indicates data showing a random number. rng_ID indicates identification information for identifying the random number. Note that the case of returning an encryption key also has the same format as FIG. 11A.
[0074] FIG. 11B shows a case where both a key and a random number are returned. key indicates data showing an encryption key. key_ID indicates identification information for identifying the encryption key. For example, when using AES as the encryption method and using the random number as an IV, the size of the random number often matches the size of one encryption key. Also, for example, when using the random number for data protection by secret sharing and using OTP for encrypted communication, there are cases where the sizes are different depending on the handling of communication data, headers of stored data, etc., but the size of the random number and the size of the encryption key generally match.
[0075] FIG. 11C shows a case where a key and a random number are returned in combination. For example, the key and IV used for AES are returned in combination.
[0076] For example, as shown in FIGS. 11A to 11C, the generation unit 6 may be such that the type of data provided in response to a request is an encryption key, the type of data provided in response to a request is a random number, or the type of data provided in response to a request is both an encryption key and a random number. In these cases, a provision message is generated by describing the provision message using the same format of message format (in the examples of FIGS. 11A to 11C, the JSON format).
[0077] [Operation Example of KM] FIG. 12 is a flowchart showing an operation example of KM20 according to the first embodiment. First, the provision unit 1 receives a request message (API call) from the application 40 (step S21). For example, at least one of an encryption key and a random number is specified in the request message. Also, for example, at least one of an encryption method, a communication destination, and a data size is specified in the request message.
[0078] Next, the determination unit 5 determines the size and number of the encryption key and the size and number of the random number according to the request message received in step S21 (step S22).
[0079] Next, KM20 performs communication (communication for sharing the same encryption key or random number) for acquiring the same encryption key or random number in the communication unit 2 with another KM20. (Step S23) This communication may be performed in advance before step S24 for acquiring data, or may be performed before step S21 or step S22.
[0080] Next, KM20 acquires data based on the determination result of step S22 (step S24). For example, when a random number is requested, the random number acquisition unit 3 acquires the requested size and number of random numbers from the random number generation module 50. Also, for example, when an encryption key is requested, the key acquisition unit 4 acquires the requested size and number of encryption keys from the QKD module 30.
[0081] Next, the generation unit 6 generates a provision message using the data acquired in step S24 (step S25). Next, the provision unit 1 provides the provision message generated in step S25 to the application 40 (step S26).
[0082] [Example of Providing Encryption Key] FIG. 13 is a diagram showing an example of providing an encryption key according to the first embodiment. First, KM20a acquires an encryption key from the QKD module 30a, and KM20c acquires an encryption key from the QKD module 30c (step S31). Next, KM20a provides the encryption key acquired in step S31 to the application 40a, and KM20c provides the encryption key acquired in step S31 to the application 40c (step S32).
[0083] Note that the encryption key to be provided may be a local key (encryption key shared by the QKD link 130) or a global key (encryption key shared by the key sharing network 120). Also, the encryption key to be provided may be an encryption key already stored in the storage device of KM20.
[0084] [Example of Providing Random Number] FIG. 14 is a diagram showing an example of providing a random number according to the first embodiment. First, KM20a acquires a random number from the random number generation module 50a, and KM20c acquires a random number from the random number generation module 50c (step S41). Next, KM20a provides the random number acquired in step S41 to the application 40a, and KM20c provides the random number acquired in step S41 to the application 40c (step S42).
[0085] Note that the random number to be provided may be a random number already stored in the storage device of KM20.
[0086] As described above, in the key management device (KM20) of the first embodiment, the communication unit 2 communicates with another KM20 to obtain the same encryption key and random number. The providing unit 1 receives a request message from the application 40 that performs encrypted data communication. The determination unit 5 determines the type of request data requested by the request message. The generation unit 6 generates a providing message including at least one of an encryption key shared by QKD via a communication network (at least one of a QKD network 120 that shares a global key and a QKD link 130 that shares a local key) and a random number according to the type of request data. Specifically, the generation unit generates a providing message including at least one of a global key shared via the QKD network 120, a local key shared via the QKD link 130, and a random number according to the type of request data. The providing unit 1 provides the providing message to the application 40.
[0087] Accordingly, according to the key management device (KM20) of the first embodiment, not only the encryption key shared by QKD but also the random number can be provided according to a request.
[0088] (Second Embodiment) Next, the second embodiment will be described. In the description of the second embodiment, the same description as that of the first embodiment will be omitted, and the differences from the first embodiment will be described.
[0089] [Example of Functional Configuration] FIG. 15 is a diagram showing an example of the functional configuration of KM20-2 of the second embodiment. The KM20-2 of the second embodiment includes a providing unit 1, a communication unit 2, a random number acquisition unit 3, a key acquisition unit 4, a determination unit 5, a generation unit 6, and a conversion unit 7. In the KM20-2 of the second embodiment, a conversion unit 7 is further added.
[0090] The conversion unit 7 converts the encryption key data for the encryption key into random number data for random numbers, or converts the random number data for random numbers into the encryption key data for the encryption key. By the processing of the conversion unit 7, a random number can be shared with another KM20-2 and made available for use as an encryption key. Also, by the processing of the conversion unit 7, an encryption key shared with another KM20-2 can be made available for use as a random number.
[0091] Also, the determination unit 5 of the second embodiment also has a function of determining whether to use the conversion unit 7 when providing at least one of a random number and an encryption key in response to a request. For example, when providing an encryption key, the determination unit 5 determines whether it is more appropriate to provide the stored encryption key or to convert a random number into an encryption key and provide it as an encryption key based on the amount of the encryption key currently stored (generated, managed) and the amount of the random number currently stored (generated, managed).
[0092] The determination of appropriateness is made based on viewpoints such as the utilization efficiency of the stored encryption key and the stored random number. For example, when a request for an encryption key is received, if the amount of the encryption key stored (generated, managed) is smaller than a threshold value, the determination unit 5 determines to convert a random number into an encryption key and provide it as an encryption key.
[0093] Specifically, when the request data is an encryption key, the determination unit 5 determines whether the accumulated amount of the encryption key in KM20-2 is smaller than a first threshold value. Next, when the accumulated amount of the encryption key is smaller than the first threshold value, the conversion unit 7 converts the random number acquired from the random number acquisition unit 3 into an encryption key. Next, the communication unit 2 encrypts the converted encryption key indicating the random number with the encryption key shared by QKD, and transmits the encrypted converted encryption key to the KM20-2 connected to the application 40 on the receiving side of the encrypted data communication. Then, the generation unit 6 generates a provision message including the converted encryption key.
[0094] By making the converted encryption key available, for example, even when a large amount of encryption keys are requested when the accumulated amount of the encryption keys is smaller than the first threshold value, the encryption keys can be provided.
[0095] Similarly, for example, when the determination unit 5 is requested for a random number, if the amount of the accumulated (generated and managed) random number is smaller than the threshold value, it determines to convert the encryption key into a random number and provide it as a random number.
[0096] Specifically, when the request data is a random number, the determination unit 5 determines whether the accumulated amount of the random number in KM20-2 is smaller than the second threshold value. Next, when the accumulated amount of the random number is smaller than the second threshold value, the conversion unit 7 converts the encryption key acquired from the key acquisition unit 4 into a random number. Next, the communication unit 2 transmits a communication notifying the unavailability or deletion of the encryption key converted into a random number to KM20-2 that shares the encryption key converted into a random number. Then, the generation unit 6 generates a provision message including a converted random number indicating the random number converted from the encryption key.
[0097] By making the converted random number available, for example, when the accumulated amount of the random number is smaller than the second threshold value, even when a large amount of random numbers are requested, random numbers can be provided.
[0098] [Operation Example of KM] FIG. 16 is a flowchart showing an operation example of KM20-2 according to the second embodiment. First, the provision unit 1 receives a request message (API call) from the application 40 (step S51). Details of step S51 are the same as those of step S21 in FIG. 12 of the first embodiment.
[0099] Next, the determination unit 5 determines the size and number of the encryption key and the size and number of the random number according to the request message received in step S51 (step S52).
[0100] Next, the determination unit 5 determines whether to convert the data for the encryption key and the random number (step S53).
[0101] When data conversion is not performed (step S53, No), the processes of steps S56 to S58 are executed. The processing when data conversion is not performed is the same as that of steps S23 to S26 in FIG. 12 of the first embodiment, and thus the description is omitted.
[0102] When converting data (step S53, Yes), the conversion unit 7 converts the data (step S54). Specifically, when converting an encryption key into a random number, the key acquisition unit 4 acquires encryption key data corresponding to the size and number of random numbers requested by the request message from the storage device of the QKD module 30 or KM20-2. Also, when converting a random number into an encryption key, the random number acquisition unit 3 acquires random number data corresponding to the size and number of encryption keys requested by the request message from the storage device of the random number generation module 50 or KM20-2.
[0103] Next, the communication unit 2 performs control communication associated with the data conversion (step S55). Specifically, when converting an encryption key into a random number, the communication unit 2 notifies another KM20-2 that shares the encryption key to be converted that the encryption key is to be converted into a random number. Also, the communication unit 2 performs communication requesting the unusability or deletion of the encryption key. Further, when converting a random number into an encryption key, the communication unit 2 encrypts the random number using the encryption key shared with another KM20-2 and transmits the encrypted random number to the other KM20-2, thereby sharing the encryption key converted from the random number with the other KM20-2.
[0104] Next, the generation unit 6 generates a provision message using the data converted in step S54 (step S57). The process of step S58 is the same as step S26 in FIG. 12 of the first embodiment, so the description is omitted.
[0105] [Example of Provision of Encryption Key Converted from Random Number] FIG. 17 is a diagram showing an example of the provision of an encryption key converted from a random number according to the second embodiment. First, KM20-2a acquires a random number from the random number generation module 50a (step S61). The conversion unit 7 converts the random number acquired in step S61 into an encryption key.
[0106] Next, KM20-2a encrypts the encryption key converted from the random number using the encryption key shared with KM20-2c, and shares the encrypted encryption key with KM20-2c by transmitting it to KM20-2c (step S62).
[0107] At this time, the security of the communication path for sharing the encryption key converted from the random number becomes equivalent to QKD because the encryption key generated and shared by QKD is used for communication encryption.
[0108] Next, KM20-2a provides the encryption key converted from the random number to application 40a, and KM20-2c provides the encryption key shared in step S62 to application 40c (step S63).
[0109] Note that the random number to be converted may be a random number already stored in the storage device of KM20-2a. Also, for KM20-2c, in the same way as in the case of KM20-2a, the random number obtained from the random number generation module 50c can be shared with KM20-2a as an encryption key.
[0110] [Example of providing a random number converted from an encryption key] FIG. 18 is a diagram showing an example of providing a random number converted from the encryption key of the second embodiment. First, KM20-2a obtains an encryption key from the QKD module 30a (step S71). The conversion unit 7 converts the encryption key obtained in step S71 into a random number.
[0111] Next, KM20-2a notifies KM20-2c that shares the encryption key to be converted that the encryption key is converted into a random number, and performs communication requesting the encryption key to be unusable or deleted (step S72). Next, KM20-2a provides the random number converted from the encryption key to application 40a (step S73).
[0112] Note that the encryption key to be converted may be either a local key (the encryption key shared by the QKD link 130) or a global key (the encryption key shared by the key sharing network 120). Further, the encryption key to be converted may be an encryption key that has already been stored in the storage device of KM20-2a. Also, for KM20-2c, in the same manner as in the case of KM20-2a, the encryption key acquired from the QKD module 30c can be provided to the application 40c as a random number.
[0113] Finally, an example of the hardware configuration of KM20(20-2) and the QKD module 30 of the first and second embodiments will be described.
[0114] [Example of Hardware Configuration] FIG. 19 is a diagram showing an example of the hardware configuration of the QKD module 30 of the first and second embodiments. The QKD module 30 includes a processor 201, a main storage device 202, an auxiliary storage device 203, a display device 204, an input device 205, a quantum communication IF 206, and a classical communication IF 207. The processor 201, the main storage device 202, the auxiliary storage device 203, the display device 204, the input device 205, the quantum communication IF 206, and the classical communication IF 207 are connected via a bus 210.
[0115] The processor 201 executes a program read from the auxiliary storage device 203 into the main storage device 202. The main storage device 202 is a memory such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The auxiliary storage device 203 is an HDD (Hard Disk Drive), a memory card, or the like.
[0116] The display device 204 displays the state of the QKD module 30 and the like. The input device 205 receives an input from the user. Note that the QKD module 30 may not include the display device 204 and the input device 205.
[0117] The quantum communication IF206 is an interface for connecting to a quantum cryptographic communication path (optical fiber link). The classical communication IF207 is an interface for connecting to the control signal communication path of QKD and to KM20 etc. When the QKD module 30 does not include the display device 204 and the input device 205, for example, the display function and the input function of an external terminal connected via the classical communication IF207 may be used.
[0118] Figure 20 is a diagram showing an example of the hardware configuration of KM20 (20-2) of the first and second embodiments. KM20 includes a processor 301, a main memory device 302, an auxiliary storage device 303, a display device 304, an input device 305, and a communication IF306. The processor 301, the main memory device 302, the auxiliary storage device 303, the display device 304, the input device 305, and the communication IF306 are connected via a bus 310.
[0119] The processor 301 executes a program read from the auxiliary storage device 303 to the main memory device 302. The main memory device 302 is a memory such as a ROM and a RAM. The auxiliary storage device 303 is an HDD, a memory card, etc.
[0120] The display device 304 displays the state etc. of KM20. The input device 305 receives an input from the user. Note that KM20 may not include the display device 304 and the input device 305.
[0121] The communication IF306 is an interface for connecting to KM20, the QKD module 30, and the application 40 etc. When KM20 does not include the display device 304 and the input device 305, for example, the display function and the input function of an external terminal connected via the communication IF306 may be used.
[0122] The programs executed by KM20 and QKD module 30 are stored in a computer-readable storage medium such as a CD-ROM, a memory card, a CD-R, and a DVD (Digital Versatile Disc) in an installable or executable file format and provided as a computer program product.
[0123] Alternatively, the programs executed by KM20 and QKD module 30 may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network.
[0124] Alternatively, the programs executed by KM20 and QKD module 30 may be configured to be provided via a network such as the Internet without being downloaded.
[0125] Alternatively, the programs executed by KM20 and QKD module 30 may be configured to be provided by being pre-embedded in a ROM or the like.
[0126] The program executed by KM20 (20-2) has a module configuration including functions that can be realized by the program among the functional configurations of the above-mentioned KM20 (20-2). The functions realized by the program are loaded into the main storage device 302 when the processor 301 reads the program from a storage medium such as the auxiliary storage device 303 and executes it. That is, the functions realized by the program are generated on the main storage device 302.
[0127] Note that part or all of the functions of KM20 (20-2) may be realized by hardware such as an IC (Integrated Circuit). The IC is, for example, a processor that executes dedicated processing.
[0128] When realizing each function using a plurality of processors, each processor may realize one of the functions or two or more of the functions.
[0129] Although some embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalent scope thereof.
Explanation of Reference Numerals
[0130] 1 Providing Unit 2 Communication Unit 3 Random Number Acquisition Unit 4 Key Acquisition Unit 5 Determination Unit 6 Generation Unit 7 Conversion Unit 10 Node 20 KM (Key Management Device) 30 QKD Module 40 Application 50 Random Number Generation Module 100 Quantum Cryptographic Communication System 110 Encrypted Data Communication Network 120 Key Sharing Network (QKD Network) 130 QKD Link 201 Processor 202 Main Memory Device 203 Auxiliary Storage Device 204 Display Device 205 Input Device 206 Quantum Communication IF 207 Classical Communication IF 210 Bus 301 Processor 302 Main Memory Device 303 Auxiliary Storage Device 304 Display Device 305 Input Device 306 Communication IF 310 Bus
Claims
1. a determination unit that determines a type of request data requested by a request message transmitted from an application that performs encrypted data communication; a generating unit that generates a provision message including at least one of an encryption key shared by a quantum key distribution (QKD) and a random number via a communication network in accordance with a type of the request data; a providing unit that provides the delivery message to the application, the request message includes at least one of a method parameter that specifies an encryption method used by the application, a communication destination parameter that specifies a communication destination of the application, and a size parameter that specifies a data size; the generation unit generates a provision message including at least one of an encryption key and a random number in accordance with the method parameter when the request message includes the method parameter, generates a provision message including at least one of an encryption key and a random number in accordance with the communication destination parameter when the request message includes the communication destination parameter, and generates a provision message including at least one of an encryption key used in encryption processing of data of a size specified by the size parameter and a random number used in encryption processing of data of a size specified by the size parameter when the request message includes the size parameter. Key management device.
2. a determination unit that determines a type of request data requested by a request message transmitted from an application that performs encrypted data communication; a generating unit that generates a provision message including at least one of an encryption key shared by a quantum key distribution (QKD) and a random number via a communication network in accordance with a type of the request data; a providing unit that provides the delivery message to the application, the generation unit generates the provision message by describing the provision message using the same message format in each of the following cases: when the type of data provided in response to the request is an encryption key; when the type of data provided in response to the request is a random number; and when the types of data provided in response to the request are both an encryption key and a random number. Key management device.
3. a determination unit that determines a type of request data requested by a request message transmitted from an application that performs encrypted data communication; a generating unit that generates a provision message including at least one of an encryption key shared by a quantum key distribution (QKD) and a random number via a communication network in accordance with a type of the request data; a providing unit that provides the delivery message to the application, When the requested data is an encryption key, the determination unit determines whether or not an accumulated amount of the encryption key is smaller than a first threshold value; a conversion unit that converts a random number into an encryption key when the accumulated amount of the encryption key is smaller than a first threshold value; a communication unit that encrypts a converted encryption key indicating an encryption key converted from the random number by the encryption key shared by the QKD, and transmits the encrypted converted encryption key to a device connected to an application on the receiving side of the encrypted data communication; The generation unit generates a provision message including the conversion encryption key. Key management device.
4. The communication network includes at least one of a QKD network sharing a global key and a QKD link sharing a local key; The generating unit generates a provision message including at least one of a global key shared via the QKD network, a local key shared via the QKD link, and a random number according to the type of the requested data. The key management device according to any one of claims 1 to 3.
5. The key management device A QKD module which is one of the devices included in the communication network; A random number generation module for generating the random numbers; The key management device according to any one of claims 1 to 4.
6. the request message includes a parameter specifying at least one of the encryption key and a random number as a type of the request data. The key management device according to any one of claims 1 to 5.
7. the request message further includes a parameter specifying the number of pieces of requested data and a parameter specifying a size of the requested data; The generation unit generates a provision message including the requested data of a size and number specified by the request message. The key management device according to claim 6.
8. When the request data is a random number, the determination unit determines whether an amount of random numbers accumulated in the key management device is smaller than a second threshold value; The conversion unit converts an encryption key into a random number when the accumulated amount of the random number is smaller than a second threshold value; The communication unit transmits a communication notifying a device that shares the encryption key converted into a random number that the encryption key converted into a random number has been disabled or deleted, The generating unit generates a provision message including a converted random number indicating a random number converted from an encryption key. The key management device according to claim 3 .
9. a cryptographic data communication network in which a plurality of applications perform cryptographic data communication; A communication network in which a plurality of QKD (Quantum Key Distribution) modules share an encryption key by QKD; a plurality of key management devices connected to the plurality of QKD modules; The key management device a determination unit for determining a type of request data requested by a request message transmitted from the application; a generating unit that generates a provision message including at least one of the encryption key and a random number in accordance with a type of the request data; a providing unit that provides the delivery message to the application, the request message includes at least one of a method parameter that specifies an encryption method used by the application, a communication destination parameter that specifies a communication destination of the application, and a size parameter that specifies a data size; the generation unit generates a provision message including at least one of an encryption key and a random number in accordance with the method parameter when the request message includes the method parameter, generates a provision message including at least one of an encryption key and a random number in accordance with the communication destination parameter when the request message includes the communication destination parameter, and generates a provision message including at least one of an encryption key used in encryption processing of data of a size specified by the size parameter and a random number used in encryption processing of data of a size specified by the size parameter when the request message includes the size parameter. Quantum cryptography communication system.
10. a cryptographic data communication network in which a plurality of applications perform cryptographic data communication; A communication network in which a plurality of QKD (Quantum Key Distribution) modules share an encryption key by QKD; a plurality of key management devices connected to the plurality of QKD modules; The key management device a determination unit for determining a type of request data requested by a request message transmitted from the application; a generating unit that generates a provision message including at least one of the encryption key and a random number in accordance with a type of the request data; a providing unit that provides the delivery message to the application, the generation unit generates the provision message by describing the provision message using the same message format in each of the following cases: when the type of data provided in response to the request is an encryption key; when the type of data provided in response to the request is a random number; and when the types of data provided in response to the request are both an encryption key and a random number. Quantum cryptography communication system.
11. a cryptographic data communication network in which a plurality of applications perform cryptographic data communication; A communication network in which a plurality of QKD (Quantum Key Distribution) modules share an encryption key by QKD; a plurality of key management devices connected to the plurality of QKD modules; The key management device a determination unit for determining a type of request data requested by a request message transmitted from the application; a generating unit that generates a provision message including at least one of the encryption key and a random number in accordance with a type of the request data; a providing unit that provides the delivery message to the application, When the requested data is an encryption key, the determination unit determines whether or not an amount of the encryption key stored in the key management device is smaller than a first threshold value; a conversion unit that converts a random number into an encryption key when the accumulated amount of the encryption key is smaller than a first threshold value; a communication unit that encrypts a converted encryption key indicating an encryption key converted from the random number by the encryption key shared by the QKD, and transmits the encrypted converted encryption key to a device connected to an application on the receiving side of the encrypted data communication; The generation unit generates a provision message including the conversion encryption key. Quantum cryptography communication system.
12. On the computer, determining a type of request data requested by a request message transmitted from an application performing encrypted data communication; generating a provision message including at least one of an encryption key shared by Quantum Key Distribution (QKD) via a communication network and a random number in accordance with a type of the request data; causing the provisioning message to be provided to the application; the request message includes at least one of a method parameter that specifies an encryption method used by the application, a communication destination parameter that specifies a communication destination of the application, and a size parameter that specifies a data size; If the request message includes the method parameter, a provision message including at least one of an encryption key and a random number is generated in accordance with the method parameter; if the request message includes the communication destination parameter, a provision message including at least one of an encryption key and a random number is generated in accordance with the communication destination parameter; if the request message includes the size parameter, a provision message including at least one of an encryption key used in encryption processing of data of a size specified by the size parameter and a random number used in encryption processing of data of a size specified by the size parameter is generated. program.
13. On the computer, determining a type of request data requested by a request message transmitted from an application performing encrypted data communication; generating a provision message including at least one of an encryption key shared by Quantum Key Distribution (QKD) via a communication network and a random number in accordance with a type of the request data; causing the provisioning message to be provided to the application; generating the provision message by having the provision message described using the same message format in each of the following cases: when the type of data provided in response to the request is an encryption key; when the type of data provided in response to the request is a random number; and when the types of data provided in response to the request are both an encryption key and a random number; program.
14. On the computer, determining a type of request data requested by a request message transmitted from an application performing encrypted data communication; generating a provision message including at least one of an encryption key shared by Quantum Key Distribution (QKD) via a communication network and a random number in accordance with a type of the request data; causing the provisioning message to be provided to the application; if the requested data is an encryption key, determining whether an amount of the encryption key stored in the computer is less than a first threshold; If the accumulated amount of the encryption key is less than a first threshold, converting a random number into an encryption key; A conversion encryption key indicating an encryption key converted from the random number is encrypted by the encryption key shared by the QKD, and the encrypted conversion encryption key is transmitted to a device connected to an application on the receiving side of the encrypted data communication; generating a provision message including the converted encryption key; program.
Citation Information
Patent Citations
JP171530A
JP1975000453A
Communication method, application apparatus, program, and communication system
JP2014068313A
Communication device, communication method, and program
JP2015179974A
Communication apparatus, communication method, program and communication system
JP2016171530A