Key management device, quantum cryptography communication system, information processing device, key management method, information processing method and program

Abstract

This reduces the operational costs of quantum cryptography communication systems in the security of communications that transmit application keys used for encryption or decryption to applications. [Solution] The key management device of the embodiment is connected to a first application by a wired communication method or a wireless communication method. The key management device includes a processing unit that, upon receiving a request for an application key used to encrypt or decrypt communications in the first application, sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device.

Description

Technical Field

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

Background Art

[0002] Quantum key distribution (QKD) technology is a technology for securely sharing a key for encrypted data communication by using single photons continuously transmitted between QKD devices connected by optical fibers. The key shared by QKD technology is guaranteed to be un窃听ed based on the principles of quantum mechanics. [[ID=

Prior Art Documents

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Non-Patent Documents

[0004]

Non-Patent Document 1

Non-Patent Document 2

[0005] However, with conventional technologies, it has been difficult to reduce the operational costs of quantum cryptography communication systems in terms of the security of communications that transmit application keys used for encryption or decryption to applications. [Means for solving the problem]

[0006] The key management device of this embodiment is connected to the first application by a wired communication method or a wireless communication method. The key management device includes a processing unit that, upon receiving a request for an application key used to encrypt or decrypt communications in the first application, sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. [Brief explanation of the drawing]

[0007] [Figure 1] A diagram showing an example of the device configuration of the QKD network according to the embodiment. [Figure 2] This diagram illustrates the process by which an application connected to QKDN obtains an encryption key from KM and performs encrypted communication. [Figure 3] A diagram showing an example of a device configuration used to describe the key management method of the embodiment. [Figure 4] A diagram showing an example of the functional configuration of the KM in the embodiment. [Figure 5] A diagram showing an example of the functional configuration of an information processing device according to an embodiment. [Figure 6] A diagram illustrating an example of processing in the processing pattern of the embodiment. [Figure 7A] This figure shows examples of Get key requests in processing patterns A1-B1-C1 and A1-B1-C2. [Figure 7B] This figure shows examples of Get key responses in processing patterns A1-B1-C1 and A1-B1-C2. [Figure 8A] This figure shows examples of transport_keys in processing patterns A2-B1-C1 and A2-B1-C2. [Figure 8B] This figure shows examples of the transport_keys response in processing patterns A2-B1-C1 and A2-B1-C2. [Figure 9A] This figure shows examples of Get key requests in processing patterns A3-B1-C1 and A3-B1-C2. [Figure 9B] This figure shows examples of Get key response in processing patterns A3-B1-C1 and A3-B1-C2. [Figure 10A] This figure shows example 1 of a Get key request in processing patterns A4-B1-C1 and A4-B1-C2. [Figure 10B] This figure shows example 1 of the Get key response in processing patterns A4-B1-C1 and A4-B1-C2. [Figure 11A] This figure shows example 2 of a Get key request in processing patterns A4-B1-C1 and A4-B1-C2. [Figure 11B] This figure shows example 2 of the Get key response in processing patterns A4-B1-C1 and A4-B1-C2. [Figure 12A]Diagram showing examples of Get key requests in the processing patterns A5 - B1 - C1 and A5 - B1 - C2. [Figure 12B] Diagram showing examples of Get key responses in the processing patterns A5 - B1 - C1 and A5 - B1 - C2. [Figure 13A] Diagram showing examples of Get key requests in the processing patterns A6 - B1 - C1 and A6 - B1 - C2. [Figure 13B] Diagram showing examples of Get key responses in the processing patterns A6 - B1 - C1 and A6 - B1 - C2. [Figure 14] Diagram for explaining the processing example of the processing pattern B2 in the embodiment. [Figure 15] Diagram for explaining the processing example of the processing pattern B3 in the embodiment. [Figure 16] Diagram showing an example of the hardware configuration of the QKD device in the embodiment. [Figure 17] Diagram showing an example of the hardware configuration of the KM and information processing device in the embodiment.

Embodiments for Carrying Out the Invention

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

[0009] In principle, the communication distance for key sharing by QKD is limited, and only one - to - one key sharing can be used. Therefore, in addition to the QKD device, a key management device (Key Manager; KM) is introduced, and a QKD network (QKDN) is configured in which the KM holds and manages keys and relays keys. In a QKDN with QKD as links and KM as nodes, cryptographic key sharing between any two points can be realized.

[0010] The shared encryption key is provided from the KM to an external application of QKDN and used by that application. Furthermore, the QKD device and KM may be integrated into a single unit within a server or other enclosure.

[0011] [Example of QKDN configuration] Figure 1 shows an example of the device configuration of the QKD network 100 according to the embodiment. The QKD network 100 according to the embodiment comprises a plurality of QKD devices 1 and a plurality of KM2. Figure 1 shows an example of the QKD network 100 with links connected between five locations A to E as shown in Figure 1.

[0012] QKD device 1 executes the QKD protocol with the opposing QKD device 1 via QKD to generate an encryption key 101 (hereinafter referred to as the "link key"). The link key is an encryption key shared between QKD devices 1 via QKD. The link key is provided to KM2 connected within the site. The link key is used for encryption and decryption of the encryption key 102 (hereinafter referred to as the "application key") generated by KM2. The application key is used for encryption and decryption of communication by the application.

[0013] KM2 is a server device that receives a link key from at least one QKD device 1. KM2 holds and manages the link key and application key, and enables cryptographic key sharing between any two KM2s by relaying the application key between KM2s. Details of key relay will be described later.

[0014] The application key is a random number generated by the KM2's random number generator, etc. The application key is shared between any two locations by being encrypted and decrypted using a link key, and then relayed between KM2 instances. The application key is provided to the application and used for its encrypted communication.

[0015] An application connects to a KM2, obtains an application key from it, and communicates encrypted with another application. The application runs on any information processing device, which is typically located at the same site as the KM2 to which the application connects. Multiple applications may be connected to a single KM2.

[0016] Locations A through E indicate the locations where QKD devices 1 and KM2 will be installed. Locations A through E are assumed to be physically secure areas, and the nodes installed at these locations are called trusted nodes. QKD devices 1 and KM2 will be installed, for example, on trusted nodes. This will ensure the storage of cryptographic keys (link keys and application keys) and the security of key relay.

[0017] It should be noted that there are various types of key relay methods in the QKD network 100. This embodiment is not limited to a specific key relay method. The above definitions of link key and application key are established for explanatory convenience, and hereafter, the key provided from KM2 to the application (the key used by the application for encrypted communication) may simply be referred to as the encryption key.

[0018] Figure 2 illustrates the process by which an application connected to the QKDN100 obtains an encryption key from the KM2 and performs encrypted communication. The notation in Figure 2 is based on the description in Non-Patent Document 2. In Figure 2, the SAE (Secure Application Entity) corresponds to the application in the embodiment. The KME (Key Management Entity) corresponds to the KM2 in the embodiment.

[0019] Step 1. At site A, SAE A calls the API (Application Programming Interface) to KME A, specifying the ID of SAE B, the encrypted communication partner, and requests an encryption key. In response, KME A provides SAE A with the encryption key and its key ID.

[0020] Step 2. SAE A notifies SAE B of the key ID of the encryption key used for encrypted communication.

[0021] Step 3. At site B, SAE B calls the API to KME B, specifying the key ID of the encryption key that was notified and the ID of SAE A with whom it will communicate encrypted, and requests the encryption key. In response, KME B provides SAE B with the encryption key and its key ID.

[0022] Through the above procedure, SAE A and B can obtain the same encryption key.

[0023] In the example in Figure 2, it is not relevant whether KME A and B are connected by a pair of QKD links or via a QKD network. Furthermore, the method by which KME A and B share and manage the relevant encryption keys (and their key IDs) (e.g., the data format of the encryption keys and the format in which the database is stored) is arbitrary.

[0024] Non-Patent Document 2 states that TLS (Transport Layer Security) is used to ensure communication security when transferring encryption keys from KM2 to applications within a site (note that in Non-Patent Document 2, the key provision API is defined as a REST API).

[0025] Typically, the site is operated securely as a "trusted node," and measures are in place to prevent physical attacks or intrusions from the outside. Unauthorized network access to the site from the outside is also blocked. Nevertheless, communication between KM2, which exchanges encryption keys using a key provision API, and the application (hereinafter sometimes referred to as "key transport") is encrypted using TLS, as stated in Non-Patent Literature 2. TLS encryption is significant as a measure against eavesdropping within the site and the risk of information leakage from within.

[0026] However, there are cases where building a Public Key Infrastructure (PKI) environment to implement TLS is undesirable due to the costs of operating a PKI and the security characteristics of PKI. In such cases, adopting communication security using a Pre-shared key (PSK), which does not depend on PKI, can be considered.

[0027] Generally, the initial PSK value is set at the time of product shipment or deployment, and that initial value is used indefinitely. However, continuing to use the initially set PSK throughout the entire operational period is undesirable from the perspective of the information leakage risk within the site mentioned above. While it is possible to embed the PSK into the product at the time of application and KM2 shipment, there is a risk of data leakage, such as the PSK, from the storage of discarded equipment when the hardware is disposed of after the product's operation has ended, so embedding the PSK should be avoided.

[0028] Therefore, it is desirable to use PSK for key management transport and to regularly update that PSK during the operational period.

[0029] However, regularly updating the TLS PSK used for key transport requires operational effort to make configuration changes. Furthermore, regularly changing the PSK value while maintaining security presents challenges in setting appropriate values ​​and carries the risk of configuration errors, thus increasing the human cost of proper operation that takes these factors into consideration.

[0030] Assuming the use cases and operational configurations described above, this embodiment describes a method for appropriately updating the PSK (Primary Key Key) in the TLS key transport security of the key provision API while reducing operational costs.

[0031] Although this embodiment will continue to use TLS for explanation, since the purpose is PSK updating, the following embodiment can be similarly applied to PSK updating using security protocols other than TLS.

[0032] [Summary of the Embodiment] In this embodiment, the PSK update to ensure the communication security of the key provision API is performed in conjunction with and integrated with the protocol operation of providing cryptographic keys from KM2 to the application. More specifically, this is as follows: (1) or (2).

[0033] (1) Request and response information for the transport key is added to the request and response messages sent from KM2 to the application to provide the key, and by exchanging transport key information in addition to the key provided, the PSK for ensuring transport security is shared between KM2 and the application, thereby re-establishing (updating) transport security.

[0034] (2) When a portion of the keys provided by KM2 to the application is specified by either KM2 or the application, that portion of the key is shared between KM2 and the application as a PSK to ensure transport security, thereby re-establishing (updating) transport security.

[0035] [Variations] There are several variations (processing patterns) in how PSK updates are performed in conjunction with and integrated with the protocol operation for providing cryptographic keys from KM2 to applications.

[0036] The first point to consider when thinking about variations is, A. The question is, from whom and at what timing will the PSK update be requested?

[0037] Specifically, for A., ​​there are the following six processing patterns. A1. The application requests KM2 to update the PSK at the time it calls the API for obtaining the key. A2. The application requests KM2 to update the PSK at a time independent of the API call for key acquisition. A3. When the application calls the API to obtain a key from KM2, it requests a PSK update from KM2 and notifies it of the ID of the PSK to be used. A4. When the application calls the API to obtain the key from KM2, it requests a PSK update from KM2 and notifies it of the PSK ID and PSK data to be used. A5. When KM2 provides the application with an encryption key in response to a key acquisition request from the application, KM2 requests a PSK update and notifies the application of the ID of the PSK to be used. A6. When KM2 provides the application with an encryption key in response to a key acquisition request from the application, KM2 requests a PSK update and notifies the application of the PSK ID and PSK data to be used.

[0038] The second point is, B. The question is whether the PSK update should be performed synchronously and at the same time between the KM2 pairs that are sharing the encryption key (in the terminology of Non-Patent Literature 2, the KME connected to the Master SAE and the KME connected to the Slave SAE), or independently, and if performed synchronously and at the same time, whether a common PSK should be used.

[0039] Specifically, for B., there are the following three processing patterns. B1. The PSK is updated independently on both the Master and Slave sides. (The PSK is updated one side at a time.) B2. The PSK is updated at the same time in synchronization between the Master and Slave sides (if the same PSK is used). B3. The PSK is updated simultaneously on both the Master and Slave sides in a synchronized manner (if different PSKs are used).

[0040] The third point is, C. The PSK to be used can be either an application key already shared between KM2s, or a different random number can be generated and used.

[0041] Specifically, for C, there are the following two processing patterns. C1. An already shared application key is used as the PSK. C2. A separately generated random number is used as the PSK.

[0042] Based on the above, there are 6 x 3 x 2 = 36 possible variations of the combinations of A to C.

[0043] [Common background] Before explaining the individual variations, the common points across all variations are as follows:

[0044] • You may or may not use TLS as the protocol.

[0045] It is assumed that data will be encrypted and communicated based on a PSK (Pre-shared key). The PSK will be used as the master secret / pre-master secret, and the encryption key (=session key) may be derived from the master secret / pre-master secret. Alternatively, the PSK may be used directly as the session key.

[0046] The encryption method used can be any method, such as OTP (One Time Pad) or AES (Advanced Encryption Standard). However, AES is usually used.

[0047] Peer authentication may be performed by verifying the PSK. Alternatively, a variation may be possible where the PSK is used solely for peer authentication, and the session key is derived using only public-key cryptography. However, in this case, the strength of the encryption depends on the public-key cryptography used for key derivation.

[0048] The PSK update frequency can be determined by any criteria. For example, the PSK may be updated every time a certain amount of time has elapsed, based on a general criterion, or every time a certain amount of communication (data volume or number of communications) is performed. Furthermore, since PSKs often use keys shared and managed by KM2, the update frequency is controlled according to the amount of keys stored and the remaining keys in KM2 or the application. For example, the more application keys stored, the higher the PSK update frequency may be controlled. Alternatively, the PSK update timing may be determined based on the application's communication (data volume or number of communications).

[0049] Figure 3 shows an example of a device configuration used to explain the key management method of the embodiment. KM2a provides an application key to the application running on the information processing device 3a. KM2a also transmits the application key, encrypted using a link key shared between KM2a and 2b, to KM2b.

[0050] KM2b decrypts the encrypted application key using a link key shared between KM2a and 2b. KM2b provides the application key to the application running on the information processing device 3b.

[0051] [Example of KM's functional configuration] Figure 4 shows an example of the functional configuration of the KM2 in this embodiment. The KM2 in this embodiment includes a processing unit 21 and a communication IF (Interface) unit 22.

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

[0053] The processing unit 21 includes a transport unit 201, a supply unit 202, an acquisition unit 203, an update unit 204, a determination unit 205, and a control unit 206.

[0054] The transport unit 201 uses a key provision API to perform communication (key transport) between the KM2 and the application.

[0055] The provisioning unit 202 provides the application key to the application in response to the application key request.

[0056] The acquisition unit 203 acquires the link key mentioned above from the QKD device 1 connected to the KM2.

[0057] The update unit 204 updates the PSK used to establish a communication session between the application and the KM2.

[0058] The determination unit 205, for example, when an application specifies information used to update the PSK (e.g., a key ID), determines whether or not the PSK can be updated based on the specified information.

[0059] For example, the determination unit 205 determines when to update the PSK. For example, the determination unit 205 increases the frequency of PSK updates as the amount of accumulated application keys increases. For example, the determination unit 205 also determines whether or not to send a PSK update request to the opposing KM2 when updating the PSK between the application and the application connected by a wired or wireless communication method.

[0060] The control unit 206, for example, uses PSK to rekey or reconnect the security protocol (e.g., TLS) used as the key transport.

[0061] The communication interface unit 22 is implemented by a communication interface that communicates using at least one of the following methods: wireless or wired. For example, the communication interface unit 22 transmits data input from the processing unit 21 to the KM2. Also, for example, the communication interface unit 22 inputs data received from the KM2 to the processing unit 31.

[0062] [Example of the functional configuration of an information processing device] Figure 5 shows an example of the functional configuration of the information processing device 3 of the embodiment. The information processing device 3 of the embodiment includes a processing unit 31 and a communication IF unit 32. The hardware implementation method of the processing unit 31 and the communication IF unit 32 is the same as that of the processing unit 21 and the communication IF unit 22 of KM2.

[0063] The processing unit 31 includes an acquisition unit 301, a transport unit 302, a control unit 303, a determination unit 304, and an update unit 305.

[0064] The acquisition unit 301 acquires the application key from the KM2 in response to a request from the application.

[0065] The transport unit 302 uses a key provision API to perform communication (key transport) between the KM2 and the application.

[0066] The control unit 303 controls at least one application, such as starting and stopping it. When multiple applications are running on the information processing device 3, communication with KM2 is performed for each application. For example, the control unit 303 uses PSK to rekey or reconnect the security protocol (e.g., TLS) used as the key transport.

[0067] The determination unit 304, for example, if information used to update the PSK (e.g., key ID) is specified from KM2, determines whether or not the PSK can be updated based on the specified information.

[0068] The update unit 305 updates the PSK used to establish a communication session between the application and the KM2.

[0069] The communication IF unit 32 transmits, for example, data input from the processing unit 31 to the KM2. Also, for example, the communication IF unit 32 inputs data received from the KM2 to the processing unit 31. Specifically, for example, the communication IF unit 32 receives an application key used for encrypting or decrypting communication between applications running on different information processing devices 3 from the KM2, which is connected to the QKD device 1 that generates link keys by QKD.

[0070] The following describes the details of the processing for the variations (processing patterns) mentioned above.

[0071] [Processing patterns A1-B1-C1 and A1-B1-C2] First, processing patterns A1-B1-C1 and A1-B1-C2 will be described. Figure 6 is a diagram illustrating processing examples in the processing patterns of the embodiment. Figure 7A shows examples of Get key requests in processing patterns A1-B1-C1 and A1-B1-C2. Figure 7B shows examples of Get key responses in processing patterns A1-B1-C1 and A1-B1-C2.

[0072] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (Get key request) and sends a message to the KM2 requesting an application key (step S1). The acquisition unit 301 adds information to this Get key request message requesting an update of the PSK (which is a security key used to transfer (transport) keys between the KM2 and the information processing device, and is therefore also referred to as a transport key).

[0073] In other words, when the acquisition unit 301 requests an application key, it requests an update of the transport key (PSK). An example of the format of the get key request message in this case is shown in Figure 7A.

[0074] In Figure 7A, {"type": key, "number": 3, "size": 256} indicates the application key request. Also in Figure 7A, {"type": transport_key, "number": 1, "size": 256, "method": AES-PSK} specifies the PSK type, the number of PSKs, the size of the PSKs, and the name of the cryptographic algorithm used for the PSKs.

[0075] Next, when KM2a receives a Get key request message from the information processing device 3a, the provisioning unit 202 sends a Get key response message, which is a message providing the application key, to the information processing device 3a (step S2). PSK (key ID and key data) information is also added to this Get key response message. An example of the format of the Get key response message in this case is shown in Figure 7B.

[0076] In the example shown in Figure 7B, the ID and key data of the PSK for security updates of the key transport are described as transport_key, alongside the application key provided to the information processing device 3a in JSON (JavaScript Object Notation) format.

[0077] Next, the information processing device 3a receives the above Get key response message from KM2a.

[0078] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0079] In processing pattern C1, the update unit 204 specifies one of the application keys held in KM2a as transport_key. The application key specified as transport_key is used to ensure the security of key transport with the application that provided that application key. For example, the control unit 206 uses the corresponding PSK to re-establish a TLS-PSK session.

[0080] The application key specified as transport_key is not used for encrypted communication between applications running on information processing devices 3a and 3b (it is controlled not to be used).

[0081] Even if a KM2b shares the application key specified as transport_key, it may be controlled not to use that application key. However, in processing pattern B2 described later, the same transport_key may be used as the PSK for updating in order to ensure the security of the key provision transport between the KM2b and the application of the information processing device 3b (PSK update).

[0082] In processing pattern C2, a random number generated by KM2 is used for transport_key. However, the JSON format of the Get key response will be the same as when the application key is used for transport_key.

[0083] When using an application key and a random number as the transport_key, the key ID (key_ID) may be unnecessary. Alternatively, the key_ID may be transformed into an appropriate format.

[0084] The appropriate key ID format for an application key may differ depending on whether it is used as an encryption key for encrypted communication between applications or as a PSK for a key transport. For example, if the application key is used as the identity in the TLS_PSK protocol, the transport unit 201 may convert the key_ID of the application key and use it as the identity.

[0085] As described above, in the examples of Figures 7A and 7B, the application key request includes specific information that identifies the number of PSKs, the size of the PSKs, and the cryptographic algorithm on which the PSKs are used. The PSK information included in the response includes identification information for the PSKs based on the specific information, and key data that identifies the PSKs based on the specific information.

[0086] Furthermore, the key data representing the PSK is either a random number different from the application key (in the case of C2), or an application key shared with another key management device (KM2b in the example of Figure 6) via encrypted transfer using a link key generated by QKD between opposing QKD devices 1 (in the case of C1).

[0087] The above describes the communication between the application of the information processing device 3a and KM2a, and the method of updating the PSK. However, the PSK is updated in a similar manner between the application of the information processing device 3b and KM2b.

[0088] [Processing patterns A2-B1-C1 and A2-B1-C2] Next, processing patterns A2-B1-C1 and A2-B1-C2 will be explained. The diagrams used to illustrate the processing examples for these processing patterns are the same as those in Figure 6. Figure 8A shows examples of transport_keys in the processing examples of processing patterns A2-B1-C1 and A2-B1-C2. Figure 8B shows examples of transport_keys responses in the processing examples of processing patterns A2-B1-C1 and A2-B1-C2.

[0089] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (transport_keys) to request a transport key update and sends a message to KM2 (step S1).

[0090] This message contains information requesting a PSK update. An example of the transport_keys message format in this case is shown in Figure 8A. The difference from the above-mentioned [processing patterns A1-B1-C1 and A1-B1-C2] is that, unlike Get key request, which requests a transport_key update at the same time as requesting a key via the API, this message is sent (only) for the purpose of updating the transport_key.

[0091] Next, when KM2a receives the transport_key message from the information processing device 3a, the providing unit 202 sends a transport_key response message to the information processing device 3a, which is a message providing the PSK (key ID and key data) (step S2).

[0092] This transport_key response message is appended with PSK (key ID and key data) information. An example of the transport_key response message format in this case is shown in Figure 8B. The difference from the above-mentioned [processing patterns A1-B1-C1 and A1-B1-C2] is that the transport_key response message in Figure 8B does not include application key information (the information returned as keys in Figure 7B).

[0093] Next, the information processing device 3a receives the above transport_key response message from KM2a.

[0094] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0095] [Processing patterns A3-B1-C1 and A3-B1-C2] Next, processing patterns A3-B1-C1 and A3-B1-C2 will be explained. The diagrams used to illustrate the processing examples for these processing patterns are the same as those in Figure 6. Figure 9A shows an example of a Get key request in the processing examples of processing patterns A3-B1-C1 and A3-B1-C2. Figure 9B shows an example of a Get key response in the processing examples of processing patterns A3-B1-C1 and A3-B1-C2.

[0096] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (Get key request) and sends a message to KM2 requesting an application key (step S1). In this Get key request message, the acquisition unit 301 specifies the ID of the application key (in the case of C1) or a random number (in the case of C2) to be used as the PSK.

[0097] In other words, in this example of processing pattern, the information processing device 3a typically specifies an application key (in the case of C1) or a random number (in the case of C2) that has been previously obtained from KM2a using an encryption key provision API, etc., as the PSK. Otherwise, it is the same as the processing patterns A1-B1-C1 and A1-B1-C2 described above.

[0098] Next, when KM2a receives a Get key request message from the information processing device 3a, the providing unit 202 reads from the storage device the application key (in the case of C1) or random number (in the case of C2) of the ID specified in the Get key request message, to be used as a PSK for encrypting communication with the application of the information processing device 3a. This application key (in the case of C1) or random number (in the case of C2) is usually an application key (in the case of C1) or random number (in the case of C2) that has already been shared between KM2a and the application of the information processing device 3a.

[0099] Subsequently, the supply unit 202 sends a Get key response message, which is a message providing the application key, to the information processing device 3a (step S2). PSK (key ID and key data) information is also added to this Get key response message. An example of the format of the Get key response message in this case is shown in Figure 9B.

[0100] In the example in Figure 9B, the Get key response message also includes PSK (key ID and key data) information. In JSON format, the PSK ID and key data for key transport security updates are typically described as transport_key, alongside the application key provided to the information processing device 3a (Keys in Figure 9B).

[0101] It is possible that the supply unit 202 may not be able to find the application key (in the case of C1) or random number (in the case of C2) corresponding to the key ID specified as the PSK. In this case, the supply unit 202 will send an error message back to the information processing device 3a.

[0102] Next, the information processing device 3a receives the above Get key response message from KM2a.

[0103] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0104] Furthermore, if the PSK ID specified by the information processing device 3a is an application key already shared between KM2a and the information processing device 3a, it corresponds to C1. If the application key corresponding to the relevant PSK ID is not shared with the information processing device 3a (i.e., the relevant application key does not exist), the application key may be generated in KM2a at this time.

[0105] As described above, in the examples of Figures 9A and 9B, the application key request includes identification information that identifies the key data used for the PSK and specific information that identifies the cryptographic algorithm on which the PSK is used. The PSK information included in the response includes identification information for the PSK based on the specific information and key data that indicates the PSK based on the specific information.

[0106] Note that the example response shown in Figure 9B is just one example and may be modified as appropriate. For example, in the example in Figure 9A, the PSK identification information (key_ID) is specified in the Get key request. If both the information processing device 3a and KM2a share the same key data, KM2a, upon receiving the PSK identification information, can identify the key data representing the PSK simply by returning information indicating that it has accepted the update of the specified PSK ({"transport_key_ack": "OK"}), as shown in the response in Figure 10B described later.

[0107] Therefore, for example, the PSK information included in the response may include at least one of the following: information indicating whether or not the use of a PSK based on specific information included in the Get key request is permitted; identification information of the PSK based on said specific information; and key data indicating the PSK based on said specific information.

[0108] [Processing patterns A4-B1-C1 and A4-B1-C2] Next, processing patterns A4-B1-C1 and A4-B1-C2 will be explained. The diagrams used to illustrate the processing examples for these processing patterns are the same as those in Figure 6. Figure 10A shows an example 1 of a Get key request in the processing examples of processing patterns A4-B1-C1 and A4-B1-C2. Figure 10B shows an example 1 of a Get key response in the processing examples of processing patterns A4-B1-C1 and A4-B1-C2.

[0109] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (Get key request) and sends a message to KM2 requesting an application key (step S1). In this Get key request message, the acquisition unit 301 specifies the ID of the application key (in the case of C1) or random number (in the case of C2) to be used as the PSK, as well as the encryption key data (application key or random number).

[0110] In other words, in this example of processing pattern, the information processing device 3a typically specifies the encryption key (application key (in the case of C1) or random number (in the case of C2)) obtained in advance from KM2a using an encryption key provision API, etc., as the PSK by specifying the ID and encryption key data. Otherwise, it is the same as the above-described [processing patterns A1-B1-C1 and A1-B1-C2].

[0111] Next, KM2a receives a Get key request message from the information processing device 3a. Then, the providing unit 202 obtains the encryption key data (application key (in the case of C1) or a random number (in the case of C2)) for the ID specified in the Get key request message from the Get key request message, to be used as a PSK for encrypting communication with the application of the information processing device 3a. The encryption key data is usually a random number newly specified by the information processing device 3a.

[0112] Subsequently, the provisioning unit 202 sends a Get key response message, which is a message providing the application key, to the information processing device 3a (step S2). An example of the format of the Get key response message in this case is shown in Figure 10B.

[0113] In the example in Figure 10B, the Get key response message also includes information indicating that the update of the specified PSK has been accepted ({"transport_key_ack": "OK"}). As shown in Figure 10B, in JSON format, information indicating that the update of transport_key has been accepted is usually described alongside the application key provided to the information processing device 3a.

[0114] Next, the information processing device 3a receives the above Get key response message from KM2a.

[0115] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0116] Furthermore, if the PSK specified by the information processing device 3a is an application key already shared between KM2a and the information processing device 3a, it corresponds to C1. If the application key corresponding to the ID of the PSK is not shared with the information processing device 3a (i.e., the application key does not exist), then the information processing device 3a generates a random number (in the case of C2).

[0117] Figure 11A shows an example of a Get key request in processing patterns A4-B1-C1 and A4-B1-C2. Figure 11B shows an example of a Get key response in processing patterns A4-B1-C1 and A4-B1-C2. As shown in Figure 11B, the ID and encryption key data specified as PSK by the Get key request may be included in the Get key response.

[0118] Furthermore, the examples in Figures 10A and 10B, and Figures 11A and 11B described above may be modified as appropriate. For example, an application key request includes identification information that identifies the key data used for the PSK, identification information that identifies the key data used for the PSK, key data that represents the PSK, and specific information that identifies the cryptographic algorithm on which the PSK is used. The PSK information included in the response may include at least one of the following: information indicating whether or not the use of the PSK based on the specific information is permitted, identification information of the PSK based on the specific information, and key data that represents the PSK based on the specific information.

[0119] [Processing patterns A5-B1-C1 and A5-B1-C2] Next, processing patterns A5-B1-C1 and A5-B1-C2 will be explained. The diagrams used to illustrate the processing examples for these processing patterns are the same as those in Figure 6. Figure 12A shows an example of a Get key request in the processing examples of processing patterns A5-B1-C1 and A5-B1-C2. Figure 12B shows an example of a Get key response in the processing examples of processing patterns A5-B1-C1 and A5-B1-C2.

[0120] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (Get key request) and sends a message to KM2 requesting an application key (step S1).

[0121] Next, when KM2a receives a Get key request message from the information processing device 3a, the provisioning unit 202 sends a Get key response message, which is a message providing the application key, to the information processing device 3a (step S2). An example of the format of the Get key response message in this case is shown in Figure 12B.

[0122] In the example in Figure 12B, the PSK ID information is also added to the Get key response message. Specifically, in the JSON format, the PSK ID for security updates of the key transport is described as transport_key, alongside the application key usually provided to the information processing device 3a.

[0123] Next, the information processing device 3a receives the Get key response message from KM2a. The update unit 305 updates the PSK using the encryption key (application key (in the case of C1) or random number (in the case of C2)) corresponding to the PSK ID contained in the Get key response message, if such an encryption key is stored in the storage device.

[0124] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0125] Furthermore, the update unit 305 may not be able to find the encryption key corresponding to the key ID specified by KM2. In this case, for example, the update unit 305 does not need to update the PSK because it cannot update it. Alternatively, for example, the update unit 305 may request KM2 to repeat the PSK update process.

[0126] [Processing patterns A6-B1-C1 and A6-B1-C2] Next, processing patterns A6-B1-C1 and A6-B1-C2 will be explained. The diagrams used to illustrate the processing examples for these processing patterns are the same as those in Figure 6. Figure 13A shows an example of a Get key request in the processing examples of processing patterns A6-B1-C1 and A6-B1-C2. Figure 13B shows an example of a Get key response in the processing examples of processing patterns A6-B1-C1 and A6-B1-C2.

[0127] First, the acquisition unit 301 of the information processing device 3a calls the key provision API (Get key request) and sends a message to KM2 requesting an application key (step S1).

[0128] Next, when KM2a receives a Get key request message from the information processing device 3a, the providing unit 202 sends a Get key response message, which is a message providing the application key, to the information processing device 3a (step S2). An example of the format of the Get key response message in this case is shown in Figure 13B.

[0129] In the example in Figure 13B, the Get key response message also includes PSK ID information and encryption key data (application key (in the case of C1) or random number (in the case of C2)). Specifically, in JSON format, the PSK ID and encryption key data for key transport security updates are described as transport_key, alongside the application key usually provided to the information processing device 3a.

[0130] Next, the information processing device 3a receives the above Get key response message from KM2a. The update unit 305 obtains the PSK (application key (in the case of C1) or random number (in the case of C2)) from the Get key response message and updates the PSK with that PSK.

[0131] Next, the information processing device 3a performs a rekeying or reconnection of the security protocol (e.g., TLS) used as the key transport using the PSK, either from the information processing device 3a to KM2a or from KM2a to the information processing device 3a (step S3). When the rekeying or reconnection is performed, the PSK used in the key transport is updated.

[0132] The examples in Figures 12A and 12B, and Figures 13A and 13B described above may be modified as appropriate. For example, the PSK information included in the response to the application request may include at least one of the PSK identification information and key data indicating the PSK.

[0133] [Processing Pattern B2] Next, processing pattern B2 will be described. Figure 14 is a diagram illustrating an example of processing pattern B2 in this embodiment. Steps S11 to S13 are the same as steps S1 to S3 (Figure 6) described above, so their explanation will be omitted.

[0134] In processing pattern B2, the determination unit 205 determines whether the PSK update between KM2a and the information processing device 3a has been completed. If the update is completed, the determination unit 205 sends a PSK update request to KM2b that includes the PSK key ID or PSK data used for the PSK update between KM2a and the information processing device 3a (step S14).

[0135] Furthermore, the determination unit 205 may decide to perform a PSK update between KM2b and information processing device 3b while a PSK update is being performed between KM2a and information processing device 3a.

[0136] Next, when the determination unit 205 of KM2b receives a PSK update request from KM2a, it determines to perform a PSK update between KM2b and the information processing device 3b by following steps S15 to S17, which are the same sequence as steps S11 to S13.

[0137] For example, PSK updates between KM2b and information processing device 3b are performed after a PSK update request is received from KM2a, triggered by a Get key response (step S15) sent from the information processing device 3b. At this time, the update unit 204 of KM2b uses the PSK ID or PSK data included in the PSK update request received from KM2a to identify the key used for PSK updates in the KM2b-information processing device 3b.

[0138] As described above, the processing unit 21 of KM2a sends a PSK update request to KM2b, which is connected to the second application, the communication destination of the first application, by a wired or wireless communication method, for establishing a second communication session between the second application and KM2b.

[0139] A PSK update request includes identification information for the PSK used to establish a first communication session between KM2a and the information processing device 3a, and specific information indicating at least one of the key data representing the PSK used to establish the first communication session. The establishment of a second communication session is carried out using the specific information.

[0140] [Processing Pattern B3] Next, processing pattern B3 will be described. Figure 15 is a diagram illustrating an example of processing pattern B3 in this embodiment. Steps S21 to S23 and S25 to S27 are the same as steps S11 to S13 and S15 to S17 (Figure 14) described above, so their explanation will be omitted.

[0141] In processing pattern B3, after or during a PSK update between KM2a and the information processing device 3a, a PSK update request is transmitted from KM2a to KM2b indicating that a PSK update has been performed between KM2a and the information processing device 3a (step S24).

[0142] In processing pattern B3, the PSK used for PSK updates between KM2b and the information processing device 3b is not specified by KM2a, which is different from processing pattern B2.

[0143] The PSK update between KM2b and the information processing device 3b is performed after receiving a PSK update request from KM2a, triggered by a Get key response (step S25) sent from the information processing device 3b.

[0144] As described above, in an embodiment of KM2 (an example of a key management device) connected to the first application by a wired or wireless communication method, when the processing unit 21 receives a request for an application key used to encrypt or decrypt communications in the first application, it sends a response to the first application that includes the application key and PSK information indicating the PSK used to establish a first communication session between the first application and KM2.

[0145] Furthermore, in the information processing device 3 of the embodiment, the processing unit 31 sends a request to the KM2 for an application key used to encrypt or decrypt communications in a first application connected to the KM2 by a wired communication method or a wireless communication method, and receives a response from the KM2 that includes the application key and PSK information indicating the PSK used to establish a first communication session between the first application and the KM2.

[0146] According to the first embodiment, the operational costs of a quantum cryptography communication system can be reduced in terms of the security of communications that transmit application keys used for encryption or decryption to an application.

[0147] Finally, an example of the hardware configuration of the QKD device 1, KM2, and information processing device 3 of the embodiment will be described.

[0148] [Example hardware configuration] Figure 16 shows an example of the hardware configuration of the QKD device 1 of the embodiment. The QKD device 1 of the embodiment includes a control device 501, a main memory 502, an auxiliary memory 503, a display device 504, an input device 505, a quantum communication IF 506, and a classical communication IF 507.

[0149] The control device 501, main memory 502, auxiliary memory 503, display device 504, input device 505, quantum communication IF 506, and classical communication IF 507 are connected via bus 510.

[0150] The control device 501 is a processor that executes a program read from the auxiliary storage device 503 into the main memory 502. The main memory 502 is memory such as ROM and RAM. The auxiliary storage device 503 is such as an HDD and memory card.

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

[0152] Quantum communication IF506 is an interface for connecting to the QKD link on which photons are transmitted. Classical communication IF507 is an interface for connecting to the transmission path on which control signals are transmitted between the opposing QKD device 1, and to the transmission path for communication with KM2, etc.

[0153] Figure 17 shows an example of the hardware configuration of the KM2 and information processing device 3 of the embodiment. The KM2 and information processing device 3 of the embodiment include a control device 401, a main memory 402, an auxiliary memory 403, a display device 404, an input device 405, and a communication IF 406.

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

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

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

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

[0158] The programs executed by the QKD device 1, KM2, and information processing device 3 of the embodiment are stored in installable or executable file format on computer-readable storage media such as CD-ROMs, memory cards, CD-Rs, and DVDs (Digital Versatile Discs) and provided as computer program products.

[0159] Alternatively, the programs executed by the QKD device 1, KM2, and information processing device 3 may be stored on a computer connected to a network such as the Internet, and provided by allowing users to download them via the network.

[0160] Furthermore, the programs executed by the QKD device 1, KM2, and information processing device 3 may be configured to be provided via a network such as the Internet without requiring downloads.

[0161] Alternatively, the programs executed by the QKD device 1, KM2, and information processing device 3 may be pre-installed and provided in ROM or the like.

[0162] Furthermore, some or all of the functions of the QKD device 1, KM2, and information processing device 3 may be implemented by hardware such as an IC (Integrated Circuit). An IC is, for example, a processor that performs dedicated processing.

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

[0164] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents.

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

[0166] Technical proposal 1 A key management device connected to a first application by a wired or wireless communication method, A processing unit, upon receiving a request for an application key used to encrypt or decrypt communications in the first application, sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. A key management device equipped with the following features. Technical proposal 2 The application key request includes specific information that identifies the number of PSKs, the size of the PSKs, and the cryptographic algorithm on which the PSKs are used. The PSK information includes identification information of the PSK based on the specified information and key data indicating the PSK based on the specified information. The key management device described in Technical Proposal 1. Technical proposal 3 The application key request includes identification information that identifies the key data used for the PSK, and specific information that identifies the cryptographic algorithm used for the PSK. The PSK information includes at least one of the following: information indicating whether or not the use of the PSK based on the specified information is permitted; identification information of the PSK based on the specified information; and key data indicating the PSK based on the specified information. The key management device described in Technical Proposal 1. Technical proposal 4 The aforementioned specific information further includes key data indicating the PSK, The key management device described in Technical Proposal 3. Technical proposal 5 The PSK information includes at least one of the identification information of the PSK and key data representing the PSK. The key management device described in Technical Proposal 1. Technical plan 6 The key data representing the PSK is either a random number different from the application key, or an application key shared with other key management devices through encrypted transfer using a link key generated between opposing QKD (Quantum Key Distribution) devices. A key management device as described in any one of Technical Proposals 2 to 5. Technical proposal 7 The processing unit transmits a PSK update request to another key management device connected to the second application, which is the communication destination of the first application, by a wired or wireless communication method, for establishing a second communication session between the second application and the other key management device. A key management device as described in any one of Technical Proposals 1 to 6. Technical proposal 8 The PSK update request includes identification information of the PSK used to establish the first communication session, and identification information indicating at least one of the key data representing the PSK used to establish the first communication session. The establishment of the second communication session is carried out using the specified information. The key management device described in Technical Proposal 7. Technical proposal 9 The aforementioned application key is shared with other key management devices by encrypted transfer using a link key generated between opposing QKD devices by QKD. The processing unit increases the update frequency of the PSK as the amount of accumulated application keys increases. A key management device as described in any one of Technical Proposals 1 to 8. Technical proposal 10 A key management device described in any one of Technical Proposals 1 to 9, An information processing device on which the first application runs, A quantum cryptography communication system equipped with [the necessary components]. Technical proposal 11 A processing unit that transmits a request for an application key used to encrypt or decrypt communications in a first application connected to a key management device by a wired or wireless communication method to the key management device, and receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. An information processing device equipped with the following features. Technical proposal 12 When a key management device connected to a first application by a wired or wireless communication method receives a request for an application key used to encrypt or decrypt communications in the first application, it sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. Key management method. Technical proposal 13 The information processing device transmits to the key management device a request for an application key used to encrypt or decrypt communications in a first application connected to the key management device by a wired or wireless communication method. The information processing device receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. Information processing methods. Technical proposal 14 On the computer, A key management device connected to the first application by a wired or wireless communication method receives requests for application keys used to encrypt or decrypt communications in the first application. The first application is instructed to send a response that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. program. Technical proposal 15 On the computer, A request for an application key used to encrypt or decrypt communications in a first application connected to the key management device by a wired or wireless communication method is sent to the key management device. The key management device receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. program. [Explanation of Symbols]

[0167] 1 QKD device 2 KM 3. Information Processing Device 21 Processing Unit 22 Communication Interface Section 31 Processing Unit 32 Communication Interface Section 100 QKD Network 201 Transport Department 202 Provision Department 203 Acquisition Department 204 Update Department 205 Judgment Department 206 Control Unit 301 Acquisition Department 302 Transport Section 303 Control Unit 304 Judgment Department 305 Update Department 401 Control Unit 402 Main storage 403 Auxiliary storage 404 Display device 405 Input device 406 Communication IF 410 Bus 501 Control Unit 502 Main storage 503 Auxiliary storage 504 Display device 505 Input device 506 Quantum Communication IF 507 Classical Communication IF 510 Bus

Claims

1. A key management device connected to a first application by a wired or wireless communication method, A processing unit, upon receiving a request for an application key used to encrypt or decrypt communications in the first application, sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. A key management device equipped with the following features.

2. The application key request includes specific information that identifies the number of PSKs, the size of the PSKs, and the cryptographic algorithm on which the PSKs are used. The PSK information includes identification information of the PSK based on the specified information and key data indicating the PSK based on the specified information. The key management device according to claim 1.

3. The application key request includes identification information that identifies the key data used in the PSK, and identification information that identifies the cryptographic algorithm used in the PSK. The PSK information includes at least one of the following: information indicating whether or not the use of the PSK based on the specified information is permitted; identification information of the PSK based on the specified information; and key data indicating the PSK based on the specified information. The key management device according to claim 1.

4. The aforementioned specific information further includes key data indicating the PSK, The key management device according to claim 3.

5. The PSK information includes at least one of the identification information of the PSK and key data representing the PSK. The key management device according to claim 1.

6. The key data representing the PSK is either a random number different from the application key, or an application key shared with other key management devices through encrypted transfer using a link key generated between opposing QKD (Quantum Key Distribution) devices. The key management device according to any one of claims 2 to 5.

7. The processing unit transmits a PSK update request to another key management device, which is connected to the second application, the communication destination of the first application, by a wired or wireless communication method, for establishing a second communication session between the second application and the other key management device. The key management device according to claim 1.

8. The PSK update request includes identification information of the PSK used to establish the first communication session, and specific information indicating at least one of the key data representing the PSK used to establish the first communication session. The establishment of the second communication session is carried out using the specified information. The key management device according to claim 7.

9. The aforementioned application key is shared with other key management devices by encrypted transfer using a link key generated between opposing QKD devices via QKD. The processing unit increases the update frequency of the PSK as the amount of accumulated application keys increases. The key management device according to any one of claims 1 to 5.

10. A key management device according to any one of claims 1 to 5, An information processing device on which the first application runs, A quantum cryptography communication system equipped with [the necessary components].

11. A processing unit that transmits a request for an application key used to encrypt or decrypt communications in a first application connected to a key management device by a wired or wireless communication method to the key management device, and receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. An information processing device equipped with the following features.

12. When a key management device connected to a first application by a wired or wireless communication method receives a request for an application key used to encrypt or decrypt communications in the first application, it sends a response to the first application including the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. Key management method.

13. The information processing device transmits to the key management device a request for an application key used to encrypt or decrypt communications in a first application connected to the key management device by a wired or wireless communication method. The information processing device receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. Information processing methods.

14. On the computer, A key management device connected to the first application by a wired or wireless communication method receives requests for application keys used to encrypt or decrypt communications in the first application. The system causes the first application to send a response that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. program.

15. On the computer, A request for an application key used to encrypt or decrypt communications in a first application connected to a key management device by a wired or wireless communication method is sent to the key management device. The key management device receives a response from the key management device that includes the application key and PSK information indicating a PSK (Pre-shared key) used to establish a first communication session between the first application and the key management device. program.

Images