Improved method for exchanging transport keys based on a quantum network with a centralized key manager; associated communication infrastructure and computer program product.

Abstract

An improved method for exchanging transport keys based on a quantum network with a centralized key manager; associated communication infrastructure and computer program product. In this method, a centralized key manager (40) maintains a database with the keys of each of the nodes (30i) of the QKD network, and, upon receiving a route to exchange a random number (K0) between a sender and a receiver, selects a key for each pair of nodes in the route and simultaneously transmits to each node in the route a command (Ci) identifying the key it shares with the preceding node and the key it shares with the following node. Each node sums (140) the two identified keys and sends a response to the XOR unit (44), which constructs a global chain (K) before transmitting it to the receiver for random number extraction. Figure for the abstract: Figure 2

Description

Title of the invention: Improved method for exchanging transport keys based on a quantum network comprising a centralized key manager; associated communication infrastructure and computer program product.

[0001] The present invention has as its general domain that of information technology security in the context of the implementation of quantum communication networks.

[0002] More particularly, the invention applies to key transfer methods based on a network implementing a quantum key distribution mechanism -QKD (“Quantum Key Distribution”).

[0003] QKD allows unconditional security of communications, including against the power of future quantum computers, which should make it possible to "break" classical cryptographic processes (in particular with the Shor algorithm, for asymmetric cryptography).

[0004] The QKD implements two quantum nodes, each integrating quantum interfaces connected to each other by an optical link.

[0005] These interfaces are adapted to generate and share a quantum key along a quantum channel established between these two interfaces along the optical link.

[0006] However, in the absence of quantum repeaters, QKD is limited in distance by the properties of the optical link. Typically, the maximum distance of an optical link supporting a quantum channel is a few tens of kilometers.

[0007] For longer distances, a QKD (or QKDN for "Quantum Key Distribution Network"), also called a quantum secure network (or QSN for "Quantum Secured Network"), is implemented. It is composed of a plurality of nodes and links. Each node is a quantum node, and each link is an optical connection between a pair of quantum nodes (more precisely, between a quantum interface of one node in the pair of quantum nodes and a quantum interface of the other node in the pair of quantum nodes). Two quantum nodes connected to each other are close enough that the optical connection supports a quantum channel enabling the implementation of the quantum key distribution mechanism – QKD.

[0008] On the QKD network, the interfaces of two quantum nodes connected by a quantum channel transmit photons which, following a reconciliation, become a series of random bits, which subsequently form a quantum key.

[0009] In addition to quantum nodes, the QKD network (“QKDN”) includes centralized entities, including a QKD network manager (“QKDN manager”) and a QKD network controller (“QKDN controller”), respectively referred to as QKDN manager and QKDN controller in the following.

[0010] Finally, the different quantum nodes are connected to each other and to the centralized entities by a classical communication network, such as an IP network, for example a public one.

[0011] To route an application key Ko (for encryption or authentication for example) from a first quantum node, or sending node, referred to as Alice in what follows, to a second quantum node, or receiving node, referred to as Mike in what follows, Alice asks the QKDN controller to define a path (or route) through the QKD network linking Alice to Mike.

[0012] If Alice and Mike are not adjacent, this path passes through one or more intermediate quantum nodes, or relay nodes.

[0013] Two successive relay nodes of this path, linked to each other by a quantum channel, constitute a segment (or hop) of the path between Alice and Mike on the QKD network.

[0014] A path is identified by a path identifier.

[0015] A path is an ordered list of the identifiers of the node interfaces quantum along this path, namely the identifiers of the two channel interfaces between Alice and the first relay node, the identifiers of the two channel interfaces between the first relay node and the second relay node, ..., the identifiers of the two channel interfaces between the nth relay node and Mike.

[0016] In this list, the channel interfaces between the relay node of rank i (i integer between 1 and n) and the relay node of rank i-1 share a quantum key K;.

[0017] Once the path has been determined, the prior art key transfer method, as presented in Recommendation - ITU-T Y.3803 entitled "Key management for quantum key distribution Networks" ("Key management for QKD networks"), of the Telecommunication Standardization Sector Study Group of the International Telecommunication Union - ITU, consists of performing chunk-by-chunk encryption / decryption:

[0018] On a request from the QKDN controller addressed to the relay node i (a request indicating the identifier of the path between Alice and Mike and the identifiers of the interfaces of the previous nodes i-1 and following nodes i+1 on this path), the node i bitwise sums the quantum key K; (then called the transport key since it is used for the transport of the application key) which it shares with the previous node i-1 with the string which it receives from the previous node i-1 via the IP network, in order to find the application key Ko to be transferred. Relay node i bitwise sums the quantum key Ki+i (called the transport key since it is used to transport the application key) that it shares with the next node i+1 and the application key Ko, and transmits the resulting string to the next node i+1 via the IP network. Node i informs the QKDN controller that it has performed the required operation. The QKDN controller can then send a request to the next node i+1. Hop-by-hop, the application key Ko is transmitted from Alice to Mike along the path determined by the QKDN controller.

[0019] However, in this key transfer process, each quantum node on the path between Alice and Mike knows the application key Ko to be transferred.

[0020] This is why the quantum nodes of the QKD network must be trusted nodes.

[0021] This strong constraint is a hindrance to the adoption of QKD networks due to the high cost of developing quantum nodes in order to comply with the level of security imposed by the classification of keys exchanged on the QKD network and the vulnerabilities induced by the presence of intermediate nodes, whether it is a lack of protection of a node or a malicious node (for example, in the case of transit through uncontrolled domains of the QKD network).

[0022] ITU-T Y.3803, however, proposes an alternative key transfer method which involves a specific entity, referred to as the "XOR node" in what follows.

[0023] The XOR node is suitable for performing XOR operations. An "XOR" operation (denoted ®) is the bitwise summation of two strings of the same size (exclusive OR operation). The result of an XOR is a string of the same size.

[0024] The XOR node is a centralized component of a Key Management System (KMS) of the QKD network. The XOR node can be independent of the quantum nodes of the QKD network or constitute an additional functionality of the receiving node, Mike.

[0025] The XOR node is accessible via the IP network by each of the quantum nodes of the QKD network.

[0026] According to this alternative process, after determining a path between Alice and Mike, the QKDN controller asks Alice to calculate a first elementary string by summing the application key Ko to be transferred with a transport key of her choice, which she shares with the intermediate node of rank 1 on the path from Alice to Mike (the request from the QKDN controller to Alice indicating the identifier of the path and the identifier of the intermediate node of rank 1).

[0027] On the one hand, Alice responds to the QKDN controller by indicating the identifier of the transport key used, KB (as well as the path identifier so that the QKDN controller can reconcile the information it receives) and, on the other hand, Alice transmits the elementary string Kq®K{ at the XOR node (as well as the path identifier so that the XOR node can reconcile the information it receives).

[0028] Then, the QKDN controller asks the intermediate node of rank 1 to sum the first transport key Ki chosen by Alice, with a second transport key of its choice, which it shares with the intermediate node of rank 2.

[0029] The intermediate node of rank 1 responds to the QKDN controller by indicating the identifier of the chosen transport key K2 and on the other hand by transmitting the elementary string K^K2 to the XOR node.

[0030] Step by step, each of the nodes i (between 0 and n-1) transmits to the XOR node the elementary chain Ke- = Æ >• ll #+1

[0031] Finally, the QKDN controller asks the XOR node to calculate a global string K by performing a global XOR operation on the set of elementary strings Këj received from the nodes on the route between Alice and Mike.

[0032] Since performing two XOR operations with the same key amounts to the identity operation, the global chain K is equal to Kq®K„, that is, to the result of the XOR operation of the application key that Alice wishes to transmit to Mike and the transport key Kn that Mike shares with the last intermediate node of the path, i.e. the node of rank n-1.

[0033] In the case where the XOR node is an additional feature of the receiving node, Mike, the latter knows the global string K.

[0034] In the case where the XOR node is independent of the destination node, the global chain K is transmitted by the XOR node to Mike. Mike then only has to perform the XOR operation between his transport key Kn and the global chain K to extract the application key Ko.

[0035] Mike can then store the application key Ko in a database to transmit it to a second application on Mike's side, at the request of this second application, for example as an encryption key for subsequent exchanges with a first application on Alice's side, the first application to which Alice transmitted the application key Ko, in response to the request of this first application.

[0036] It should be noted that the term "key to be transferred" covers the case of the concatenation of a sequence of random bits (which constitutes a key in the strict sense) with metadata associated with this key (such as an identifier, a creation date, etc.).

[0037] In the remainder of this document, we will refer to "keys", without losing sight of the fact that this covers various possible implementation cases, including a key such as "useful randomness" or a key such as "useful randomness augmented with metadata".

[0038] According to this alternative key transfer method, the intermediate nodes of the QKD network no longer have the immediate ability to know the application key Ko to be routed. Only the QKD network access nodes (the rank 1 node for Alice and the rank n-1 node for Mike) possess important pieces of knowledge: the rank 1 node has direct knowledge of the transport key Ki and can use it to recover the key Ko by intercepting the message transmitted by Alice to the XOR node containing the sum K0®Ki; similarly, the rank n-1 node has direct knowledge of the transport key Kn and can use it to recover the key Ko if it intercepts the message transmitted to Mike by the XOR node and which contains the global key Ko®Kn-

[0039] The aim of the present invention is therefore to propose improvements to the previous key transfer method based on a QKD network, in order to improve its security and increase the speed of execution.

[0040] To this end, the invention relates to a method for exchanging an application key in a communication infrastructure, the communication infrastructure comprising a "quantum" communication network implementing a quantum key distribution mechanism, or QKD network, the QKD network comprising a plurality of quantum nodes, two quantum nodes linked on the quantum network being connected by a quantum channel whose two interfaces, respectively hosted by each of the two quantum nodes, are adapted to generate and share at least one quantum key, said quantum key being saved in a local database of each of said two quantum nodes, characterized in that the QKD network further comprises a controller adapted to define a route on the QKD network, a centralized key manager and a computing unit, or "XOR unit",Since the various components of the QKD network are connected to a "classic" communication network, the process includes the following steps:

[0041] - each time a key is modified in a node's local database quantum, transmission, by said quantum node, to the centralized key manager, of a set of information associated with the modified key, the set of information including an identifier of the modified key and a size of the modified key, and, if the modified key is a quantum key, an identifier of the interface of the quantum node which is associated with the modified key, and storage, by the centralized key manager, of the set of information in a central database;

[0042] - following the receipt, by the controller, of a route request containing a size required application key, an identifier corresponding to a sending quantum node and an identifier corresponding to a receiving quantum node, determination, by the controller, of a route on the QKD network between the sending quantum node and the receiving quantum node, via a plurality of relay quantum nodes, and transmission of the determined route to the centralized key manager, the route being identified by a route identifier and corresponding to an ordered list of quantum channel interfaces between quantum nodes which allow linking the sending quantum node and the receiving quantum node, said interfaces being associated with quantum keys whose size is adapted to the required size of application key;

[0043] - selection of the application key by the centralized key manager in the database central data based on the application key size, among the keys associated with the emitting quantum node present in the central database, and indication to the emitting quantum node of the selected application key;

[0044] - generation of a command, by the centralized key manager, for each quantum nodes of the route, the command for the sending quantum node, respectively the receiving quantum node, giving the identifier of a quantum key shared with a first relay quantum node, respectively a last relay quantum node, along the route, and the command for an i-th relay quantum node giving the identifier of a quantum key shared with the previous quantum node and the identifier of a quantum key shared with the next quantum node, along the route, each command further incorporating a message identifier corresponding to the route identifier, the keys of the commands being selected by the centralized key manager in the central database taking into account the route determined by the controller and the application key size;

[0045] - sending, in parallel, to each of the quantum nodes of the route, the command corresponding;

[0046] - summation, by the i-th quantum relay node, of the two quantum keys whose key identifier appears in the received command, to obtain an elementary string, and for the sending quantum node, of the quantum key whose key identifier appears in the received command and the application key, and sending a response to the XOR unit containing the elementary string resulting from the summation and the message identifier;

[0047] - calculation, using the XOR unit, of a global chain by summing the elementary chains received from each of the quantum relay nodes and the transmitting quantum node which are associated with the route according to the message identifier;

[0048] - transmission, via the XOR unit, of the global chain to the quantum node RECIPIENT ;

[0049] - extraction, by the recipient quantum node, of the application key, by summing the global chain and the quantum key specified in the command received from the centralized key manager.

[0050] According to particular embodiments, the process comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0051] - the method further comprising, for initiating the exchange of an application key: transmission, by a first application, to the sending quantum node, of a request to exchange an application key with a second application, including an identifier of the second application, and the application key size; transmission, by the sending quantum node, to the centralized key manager, of a request including an identifier of the sending node, an identifier of the second application and the application key size; transmission, by the centralized key manager, to a QKD network manager, of a request to identify the destination node associated with the second application; and, transmission, by the centralized key manager, to the controller of a request to calculate a route containing the identifier of the sending quantum node, an identifier of the destination quantum node, and the application key size;

[0052] -the centralized key manager: develops a lookup table associating a plurality of message identifiers with the route identifier; transmits the lookup table to the XOR unit; and generates a command to a particular quantum node of the route by incorporating a message identifier selected from the plurality of message identifiers, the response from a particular quantum node taking up said message identifier, and the XOR unit determining the route corresponding to the response received from the message identifier and the lookup table, the XOR unit summing the elementary keys associated with the same route identifier;

[0053] - the centralized key manager also performs fictitious exchanges with quantum nodes of the QKD network, by issuing commands whose message identifier is fictitious and is not associated with any route identifier in the lookup table;

[0054] - a fictitious message identifier is selected so as to be identified as that such by the quantum node receiving the command, said quantum node then generating two random events and transmitting the sum of these two random events as an elementary key in the response sent to the XOR unit;

[0055] - the centralized key manager generates metadata during the exchange of the application key and shares said metadata with the sending quantum node and / or the receiving quantum node:

[0056] The invention also relates to a communication infrastructure adapted for implementing the preceding method, comprising a "quantum" communication network implementing a quantum key distribution mechanism, or QKD network, the QKD network comprising a plurality of quantum nodes, two quantum nodes linked on the quantum network being connected by a quantum channel whose two interfaces, respectively hosted by each of the two quantum nodes, are adapted to generate and share at least one quantum key, said quantum key being stored in a local database of each of said two nodes, the QKD network further comprising:

[0057] - a QKDN network controller, adapted to calculate a route based on a application key size, between a sending quantum node and a receiving quantum node;

[0058] - a centralized key manager, interfacing between the quantum nodes and the controller, maintaining a central database storing a set of information for each key present in each local database of each quantum node in the QKD network, the set of information comprising at least an identifier and a corresponding key size; and,

[0059] - a calculation unit or XOR unit,

[0060] the various components of the communication infrastructure being connected via a "classic" communication network.

[0061] The invention also relates to a centralized key manager adapted to be integrated into the previous infrastructure.

[0062] Preferably, the XOR unit is a feature of the centralized key manager.

[0063] The invention also relates to a computer program product comprising instructions which, when executed by a computer, allow the implementation of the steps of the previous process which are associated with a component of the previous infrastructure.

[0064] The invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the drawings in which:

[0065] [Fig-1] [Fig.1] is a representation in the form of functional modules of a method of implementing an infrastructure according to the invention;

[0066] [Fig.2] [Fig.2] is a block representation of an embodiment of a key transfer method according to the invention, this method being implemented by the infrastructure of [Fig.1].

[0067] In what follows, when we speak of the sum of two bit strings, we mean performing the bitwise sum of these two strings, that is to say, applying the XOR operator (exclusive OR operation). The result obtained is a string of the same length.

[0068] A key is a special type of string, insofar as it is intended to be used for its random and confidential nature (shared only with identified recipients), particularly for encrypting another key or data. On the other hand, one uses more simply the term "string" for the case of a sequence of bits intended to carry information (for example, encrypted data, an "XOR" calculation, etc.). STRUCTURE

[0069] A first embodiment of the invention will be presented with reference to [Fig.1].

[0070] The quantum communication infrastructure – QCI (“quantum communication infrastructure”) 1 comprises a quantum network, or QKD network 2, and a “classical” (as opposed to “quantum”) communication network, referred to as the IP network in the following. It is referenced by the number 3 in [Fig. 1].

[0071] IP network 3 is for example a wide area network - WAN (“Wide Area Network”).

[0072] To increase the security of communications on the IP network 3, the link between two components of the infrastructure 1 is preferably authenticated according to best practices (for example, by implementing post-quantum or hybrid signature techniques). This aspect is outside the scope of the present invention.

[0073] The QKD 2 network comprises: a plurality of quantum nodes 30; a QKD network manager, or QKDN “manager” (“QKDN manager”) 52; a QKDN controller (“QKDN controller”) 50; and a centralized key manager – CKMC (“Centralized Key Manager Controller”) 40.

[0074] For the implementation of the method according to the invention, a centralized component is provided as an interface between the quantum nodes, on the one hand, and the controller 50 and the manager 52, on the other hand. This centralized component is part of the QKD 2 network's Key Management System (KMS), as are the KM modules of the quantum nodes. This centralized component is called the Centralized Key Management Controller (CKMC). It is designated as part 40 in [Fig. 1].

[0075] The QKDN 52 manager is connected to the IP 3 network via a conventional 4152 link.

[0076] The QKDN 50 controller is connected to the IP 3 network via a conventional 4150 link.

[0077] The CKMC 40 is connected to the IP 3 network via a conventional 4140 link.

[0078] The QKDN 52 manager is updated with an initial mapping of the QKD 2 network topology at network commissioning.

[0079] During the operation of the QKD 2 network, the manager 52 receives alarms reported by the KM modules of the quantum nodes, via the CKMC 40. These alarms, which indicate the current state of each quantum node of the network, allow a dynamic update of the initial map, in order to obtain a current map 53 of the topology of the QKD 2 network and thus be able to ensure network supervision functions.

[0080] The mapping lists in particular the quantum nodes, the identifiers of the quantum nodes on the network 3, the identifiers of the interfaces of each channel connecting two quantum nodes of the QKD 2 network, as well as the identifiers of the applications associated with each node.

[0081] Upon request from CKMC 40 (said request including the identifier of an application), controller 50 is adapted to identify the network node 2 which is associated with that application.

[0082] The QKDN controller 50 is adapted to regularly download the current map from the manager 52. Alternatively, the QKDN controller 50 is adapted to download the initial map from the manager 52, and then to update it so as to obtain the current map of the QKD 2 network topology, from the alarms, which are brought up by the quantum nodes, for example via the CKMC 40.

[0083] Communication between the controller 50 and the manager 52 is carried out for example via the IP network 3.

[0084] The controller 50 also receives service messages from the CKMC 40 indicating the current "bit stock", i.e. the number and size of keys available for each interface of each quantum node of the QKD network 2. Communication between the controller 50 and the QKDN 40 takes place via the IP network 3.

[0085] This information (current mapping and bit stock) allows the controller 50 to define an addressing plan 51, on the basis of which it can then calculate optimal routes.

[0086] Upon request from CKMC 40, said request including the identifier of two quantum nodes of network 2 (which are not adjacent, i.e. in direct connection by a quantum channel) and the size of the key to be transferred between these two nodes, the QKDN controller 50 is adapted to define a path, or route, on the QKD 2 network between these two quantum nodes, as end nodes of this route.

[0087] The route determination process implemented by the QKDN 50 controller is in accordance with the prior art.

[0088] The QKDN 50 controller is thus suitable for determining a route in the form of an ordered list L of the identifiers of the quantum interfaces constituting the endpoints of each hop between quantum nodes along this route. A route is associated with a route identifier, ID_Route.

[0089] The QKDN 50 controller is suitable for sharing the calculated route with the CKMC 40.

[0090] In [Fig. 1], only the quantum nodes of the path defined by the QKDN 50 controller between a 3Oo emitting quantum node, referred to as Alice in what follows, and a 30n receiving quantum node, referred to as Mike in what follows, have been shown.

[0091] This route passes through a succession of quantum relay nodes, which are indexed by the integer i, between 1 and n-1. In [Fig.1], the transmitter-side access node, 30i, of the intermediate nodes, 30m, 30;, 30i+1, and the receiver-side access node, 30„ i, of the route from Alice to Mike are shown.

[0092] The quantum node of rank 0 of this route is none other than the sending user node, Alice, and the quantum node of rank n of this route is none other than the receiving user node, Mike.

[0093] Two successive quantum nodes of this route are connected by a quantum channel, which is established, along an optical link, between two quantum interfaces belonging respectively to each of these two nodes (note that a quantum node can have more than two interfaces to establish quantum channels with as many neighboring quantum nodes). In [Fig. 1], the channels and the interface pairs associated with each channel are respectively referenced 31;, 312, 31m, 3h, 31i+131i+2, 3 ln_i and 31n.

[0094] The quantum interfaces of a quantum channel allow one or more quantum keys to be generated and exchanged regularly.

[0095] Each quantum node is equipped with a key management module - KM. This is a logical grouping of an LKMC module 34;, a key relay module 32;, a KMA 33; and a KSA 36; (in [Fig.1], only the KSAs, 360 and 36n, of the sending and receiving nodes are shown), these different modules being in mutual communication via a communication bus of the node in question.

[0096] The KMA (“Key Management Agent”) 33; is a local component of the key management system - KMS (“Key Management System”) of the QKD 2 network.

[0097] The KMA 33; of node 30; is adapted to manage a local database 35; of node 30;. This local database contains each quantum key generated and shared by a quantum interface of node 30;.

[0098] The local database 35; thus stores the quantum keys K; valid at the current time on each of the quantum channels originating from the node 30; considered. In this database each key K; is associated with a set of information, including a key identifier ID_K; and a key size, L_K;.

[0099] Fig. 1 shows only the quantum keys used during a particular key exchange, or transport keys.

[0100] Thus Alice and the first relay node 30; share a transport key K; ; the first relay node 30; and the second relay node share a transport key K2; the previous node 30; i and the current node 30; share a transport key K; the node current 30; and the next node 30i+1 share a transport key Ki+i; and the relay node 30n i and Mike share a transport key Kn.

[0101] A Local Key Manager Component (LKMC) 34; ensures exchanges, via the IP 3 network (to which the LKMC is connected by a conventional link 41;) with the various components of the infrastructure. Each LKMC (and consequently each node) is identified by an identifier on the IP 3 network. The identifier of a quantum node can be taken to be equal to the identifier of its LKMC module.

[0102] The LKMC 34; is adapted to, upon information from the KMA 33; that a modification has been made in the local database 35;, transmit an update message to the CKMC 40. Such a message includes in particular the information elements associated with a key newly stored in the local database 35;.

[0103] In particular, the LKMC is adapted to interpret commands received from the CKMC 40 and to command / query the other functional modules of the node it equips to carry out these commands: to ask the KMA to extract from the local database the two keys whose identifiers are indicated in the received command; to ask the key relay module to sum said two keys; and to transmit to the XOR module of the CKMC the result of this summation.

[0104] The Key Relay module 32 is adapted to perform, on command from the LKMC, the bitwise summation of two keys stored in the local database 35 and extracted by the KMA 33. The result of this operation is an elementary string Ke. The module 32 is designed to address this result to the LKMC 34.

[0105] For example, module 32; of relay node 30; is adapted to compute the elementary chain Ke; resulting from the sum of the quantum keys K; and Ki+1 stored by relay node 30; :

[0106] Ke^K^K^

[0107] The sending node, Alice, includes: a key management agent - KMA 330, a local key storage database 350, a key relay module 32o, an LKMC 340, a key supplier agent - KSA (“Key Supplier Agent”) 36o associated with an application key storage volume 15, and a first application 10.

[0108] An application is in fact co-located, connected or associated with a node. The first application 10 does not access the encryption key storage volume 15 associated with the KSA 360 directly, but via the KSA 360.

[0109] It should be noted that a local database 35 stores quantum keys, but can, in addition, store "non-quantum" keys, in the sense that they are generated differently, for example by a suitable application associated with the node in question and passing through the KMA 30; of the node considered to load a key and its information elements into the local database.

[0110] Similarly, the receiving node, Mike, comprises: a KMA 33n associated with a local database 35n, a key relay module 32n, an LKMC 34n, a KSA 36n associated with an application key storage volume 25, and a second application 20. The second application 20 does not access the application key storage volume 25 associated with the KSA 36n directly, but via the KSA 36n.

[0111] The centralized key manager - CKMC 40 of the QKD 2 network is connected to the IP 3 network by a conventional link 4140. For this purpose, it includes a communication interface 42, adapted to communicate via the IP 3 network with the other components of the infrastructure 1.

[0112] The CKMC 40 is identified by its IP address on the IP network 3.

[0113] In the preferred embodiment illustrated in the figures, the CKMC 40 incorporates a XOR unit 44.

[0114] In particular, the XOR unit 44 processes messages which originate from nodes 30; and include elementary strings Ke;.

[0115] The XOR 44 unit is adapted to sum the elementary chains Ke; originating from the quantum nodes of the same route, that is to say, originating from all the quantum nodes along the route between Alice and Mike. The result of this summation is a global chain K.

[0116] Given that summing the same key twice is equivalent to performing the identity operation, the global chain K therefore respects the relation:

[0117] k = (kq®k^®{ki®k^ © ... ©(^©^©(æ.®^])®^®^)® ... ©(^(©æJ

[0118] The XOR unit 44 is adapted to transmit the global string K to the recipient, Mike, via interface 42 and the IP network 3.

[0119] The CKMC 40 includes a central database 45 storing the information elements of the keys available in the local database 35; of each of the quantum nodes of the quantum network 2.

[0120] The central database 45 of the CKMC 40 has an entry for each valid key K;. Associated with this entry is a key identifier ID_K;, the size of this key K;, and, if it is a quantum key, the identifier of the interface 31; which participated in the generation of this key.

[0121] To keep the contents of the central database 45 up to date, the CKMC 40 is adapted to process update messages received from the LKMC 34; quantum nodes declared in the map received from the manager.

[0122] The CKMC 40 is adapted to regularly transmit the contents of the central database to the controller 50, in the form of a "bit bank". The latter indicates, for each interface of each quantum node, the number of valid quantum keys and the size of each of these quantum keys.

[0123] The CKMC 40 preferably includes a matching unit 48 for masking the identifier of a route from the quantum nodes, using a matching table T. The matching table associates a route identifier ID_Route with a plurality of command message identifiers, ID_Message.

[0124] The CKMC 40 is suitable for relaying service messages (such as alarms) issued by quantum nodes to the QKDN 52 manager, in particular for updating the map describing the current topology of the QKD network. PROCESS

[0125] With reference to [Fig.2], an embodiment of the encryption key exchange method according to the invention will be presented.

[0126] The process 100, implemented by infrastructure 1 of [Fig.1], comprises the following successive steps.

[0127] The local database 35; of a quantum node 30; (i between 1 and n) stores quantum keys, generated by one or the other of the interfaces of the quantum node 30;, and, possibly, other keys, generated for example by a random key generation application, which is associated with the quantum node.

[0128] In the local database 35;, a key K; is associated with a set of information. This set includes at least one identifier of the key ID_K;, as well as a key size. If it is a quantum key, this set also includes the identifier of the interface for which this quantum key is valid. This set may also include metadata associated with the key K;.

[0129] At each modification of the content of the local database 35; (addition of a key, deletion of a key, etc.), the KMA 30; and the LKMC 34; of the quantum node 33; generate an update message to the CKMC 40. This update message contains the set of information associated with the modified key.

[0130] From the update messages it receives, the CKMC 40 keeps the contents of the central database 45 up to date. In particular, it stores the set of information for each key present in a local database of the quantum network 2.

[0131] Furthermore, from the commissioning of network 2, the QKDN 52 manager has an initial map of the topology of network 2. The initial map can, for example, be prepared by a network operator and stored in the memory of a computer constituting the QKDN 52 manager.

[0132] The QKDN 52 manager updates the network topology map 2 as the network evolves.

[0133] For this purpose, each node 30 regularly transmits alarms to the CKMC 40, which forwards them to the manager 52. An alarm indicates the current state of the applications that are associated with the alarm-emitting node and / or the current state of each of the interfaces of the alarm-emitting node.

[0134] The QKDN manager 52 provides this updated network map as the current map 53.

[0135] The update of the current mapping 51 of the QKDN controller 50 is carried out via the QKDN manager 52.

[0136] Furthermore, the QKDN 50 controller receives service messages from the CKMC 40 indicating the current "bit stock", i.e., the number and size of keys available for each interface of each quantum node of the network 2.

[0137] The current mapping and bit stock enable the controller 50 to define an addressing plan 51.

[0138] The first application 10, connected to the quantum node Alice 300, then wishes to exchange with the second application 20, connected to the quantum node Mike 30n.

[0139] To encrypt these exchanges, an application key shared between the first and second applications is used.

[0140] To share an application key between the first and second applications, process 100 is implemented.

[0141] According to this process, the first application 10 indicates to Alice that it wants to retrieve an application key of a certain size Lo for the subsequent encryption of its exchanges with the second application 20.

[0142] To this end, in a step 110, the first application 10 sends a request to Alice's KSA 360. This request provides the identifier of the second application 20 and the size Lo of the required application key.

[0143] In step 111, Alice's KSA 360 sends a request to CKMC 40 (via LKMC 340). This request, which includes Alice's identifier, ID_A, includes the size Lo of the requested application key and the identifier of the second application 20.

[0144] In step 112, the CKMC 40 queries the manager 52 by indicating the identifier of the first and second applications, 10 and 20.

[0145] In step 113, manager 52 checks whether the first application 10 has permission to perform a key transfer to the second application.

[0146] If so, manager 52 retrieves, from the identifiers of the first and second applications, 10 and 20, and from the current mapping 53 of network 2, the identifier of the quantum node associated with the first application 10, in this case the identifier of Alice, and the identifier of the quantum node associated with the second application 20, in this case Mike's identifier, determines if these nodes are neighbors on network 2 (directly connected to each other via a quantum channel).

[0147] In step 114, manager 52 responds to CKMC 40 by giving the identifier of Mike and if it is a neighboring node of Alice (step 114), if it is neighboring nodes, process 100 goes to step 118.

[0148] If these are not neighboring nodes, this means that the transfer of the application key will have to rely on relay nodes.

[0149] In this case, in step 115, the CKMC 40 sends a route request to the QKDN controller 50.

[0150] This route request indicates the size Lo of the application key to be transferred and the identifier of the first application and the identifier of the second application.

[0151] Alternatively, the route request does not give the identifiers of the first and second applications, but the identifiers of the Alice and Mike nodes, which makes it possible to hide the identifiers of the applications from the controller 50 and thus ensure a better level of security.

[0152] In step 116, controller 50 determines a route on the QKD network between Alice and Mike. For this, it takes into account the current mapping 51 of the QKD network 2.

[0153] To establish the route, controller 50 takes into account, in particular, the size of the application key to be exchanged. Indeed, for bit-by-bit summation operations, quantum keys of the same size as the application key Ko must be used. Therefore, nodes whose interfaces share quantum keys of a suitable size must be chosen.

[0154] This route takes the form of a list. It is an ordered list of the identifiers of the 3h interfaces of the quantum nodes 30; from Alice (i=0) to Mike (i=n).

[0155] This list is associated with a route identifier, ID_Route.

[0156] In step 117, controller 50 sends back the route it has generated to CKMC 40.

[0157] In step 118, the CKMC 40 selects, from the central database 45, a A key of size Lo among the keys available in Alice's local database 350 as an application key of size Ko. When the route has multiple segments, it can be a quantum key or a non-quantum key. When the route has a single segment, it is a quantum key shared between Alice and Mike.

[0158] In step 119, when the route has several segments, for each segment of the route ID_Route, the CKMC 40 selects, from the central database 45, a quantum key shared between the two interfaces of the end quantum nodes of the segment under consideration and having the required size Lo. For example, the CKMC selects the key K; shared between the interfaces 31; of the nodes 30; |Ct 30;.

[0159] In step 120, the CKMC 40 elaborates a C command; to each of the 30 nodes; identified along the route ID_Route, for i between 0 and n.

[0160] The command Q (i between 1 and n-1) to node 30; indicates the route identifier, ID_Route, the identifier ID_K; of the previously selected key K; and the identifier of the interface with the previous node 30; i of the route, as well as the identifier ID_Ki+i of the previously selected key Ki+i and the identifier of the interface with the next node 30i+i of the route.

[0161] The Co command to node 3Oo indicates the route identifier, ID_Route, and the identifier ID_K; of the key K; shared with the next node 30; and the identifier of the transport key Ko previously selected in step 118.

[0162] The Cn command to node 30n indicates the route identifier, ID_Route, and the identifier ID_Kn of the key Kn shared with the previous node 30„ ।. The structure of this command allows Mike to be told which key will be used in step 170. Node 30nne does not respond to such a command.

[0163] When the route has a single segment, i.e. Alice and Mike being neighbors, the CKMC 40 elaborates a similar command for Alice and Mike, with the transport key identifier Ko selected in step 118.

[0164] Advantageously, in a command, the centralized key manager 40 replaces the route identifier ID_Route with a message identifier ID_Message, in order to hide the route identifier from the quantum node 30; recipient of the command C,.

[0165] In this case, the CKMC 40 chooses a different message identifier for each command from among the various commands addressed to the nodes of the route. The uniqueness of a message identifier makes it possible to decouple the commands sent to the quantum nodes of the same route and thus increase protection in case of interception of the commands or the responses to these commands. Indeed, thanks to the uniqueness of the message identifiers, in case of interception of a command or its response, the attacker will not be able to determine which route, and therefore which transport key transfer, this message contributes to.

[0166] For this purpose, the CKMC 40 constructs a lookup table T between the route identifier and the message identifiers actually used in the preparation of the commands C;.

[0167] The CKMC 40 shares the T lookup table with the XOR 44 unit.

[0168] In step 130, the Q commands are sent in parallel by the CKMC 40 to the LKMC 34; of the different quantum nodes 30;.

[0169] Parallelizing the sending of commands by the centralized key manager 40 to the different quantum nodes along the route between Alice and Mike saves time in executing the transfer of the transport key Ko between Alice and Mike, compared to the prior art, which performs this same transfer by putting implements a sequential sending of key pair summation instructions to the various quantum nodes located along the route between Alice and Mike.

[0170] This also reduces the probability that the quantum key selected for a section of the road between Alice and Mike is actually outdated by the time the quantum nodes in that section are asked to use that key.

[0171] Parallelization also makes it possible to reduce the probability that a quantum node along the route between Alice and Mike, or rather the interface of that node, will fail after the selection of the route to follow, but before that node has been asked to use that key, since at the time of the route selection all the nodes of the route are operational.

[0172] In the case of a single-segment route, Alice and Mike interpret the received command (a command incorporating, for example, a binary field taking the value of one when the route has one segment and the value of zero when the route has multiple segments) as sufficient to move the key Ko indicated in the command, from the local database to the encryption database, respectively on Alice's side and on Mike's side.

[0173] In the case of a route with several segments, in step 135, the Co command is first interpreted as indicative of the application key Ko selected by the CKMC 40 and to be used by the first application 10 for its exchanges with the second application 20. In step 135, the KMA 360 of Alice stores the application key Ko in the key storage volume 15.

[0174] Still for the case of a route with several segments, in a step 140, at the level of each quantum node of the route, the command C; is interpreted by the LKMC 34; recipient as a request to calculate the sum of the previous keys K; and next Ki+i in an elementary chain Ke;.

[0175] Thus, in step 140, the LKMC 34 requests the KMA 33 to extract from the local database 35 the two keys that correspond to the identifiers indicated in the command C. Then, the key relay module 32 performs the summation of these two quantum keys at the request of the LKMC 34.

[0176]

[0177] It should be noted that the local database of a node stores many quantum keys, but the choice of the two keys to be summed from the set of available keys is made by the CKMC 40.

[0178] The LKMC 34; then transmits the elementary string Ke; obtained, in a reply message R;, to the XOR module 44 of the CKMC 40.

[0179] The response R; includes the route identifier (or message identifier when this variant is implemented), information which is taken from the incident Ci command, as well as the elementary string Ke;.

[0180] In step 150, the XOR 44 unit of the CKMC 40 processes the responses received.

[0181] If the response includes a message identifier, the XOR 44 unit uses the table of T-matching to find the identifier of the associated route.

[0182] The XOR 44 unit then calculates a global string K from the elementary strings Ke; of the responses R; (i between 0 and n-1) attached to the same route ID_Route.

[0183] The result of this operation is the global chain K:

[0184] 0^0^0(^.0^)0(^0^^

[0185] That is:

[0186] K = KQ®Kn

[0187] In step 160, the XOR unit 44 transmits the global K chain to Mike's KMA 36n along the 41n link.

[0188] At step 170, Mike's KMA 36n sums the global chain K with Mike's quantum key Kn, the identifier of the key Kn having been provided in the command Cn.

[0189] This allows Mike to extract the Ko application key.

[0190] In step 180, Mike's KMA 36n stores the application key Ko in the key storage volume 25.

[0191] This application key can then be used for encrypted exchanges between the first and second applications 10 and 20, for example directly via the IP network 3. Variants

[0192] In a first embodiment, metadata is associated with the global key K, which is transmitted to Mike by the centralized key manager CKMC 40.

[0193] This metadata, such as the end-of-life date, the Epsilon security parameter, etc., is generated by the centralized key manager 40, for example after the XOR unit 44 has determined the value of the global key K.

[0194] This metadata advantageously depends on the metadata associated with the quantum keys used for the transfer. The metadata associated with a quantum key can be defined by the KMA 33i of the quantum node at the time of its generation and storage in the local database 35;. The metadata is transmitted to the CKMC 40 in update messages as data from the information set associated with a key.

[0195] Then the metadata of the global key K are transmitted in a dedicated message on the one hand to Mike and on the other hand to Alice.

[0196] These metadata can be associated, by each of the users Alice and Mike, with the application key Ko exchanged.

[0197] With this mechanism, metadata relating to the application key Ko are shared between Alice and Mike without needing to use one or more other transport keys to encrypt the communication of this metadata directly between Alice and Mike via the IP network.

[0198] In a second embodiment, during a key transfer, dummy exchanges are advantageously carried out between the centralized key manager 40 and the quantum nodes 30 of the quantum network.

[0199] In a first example, a command message with a message identifier that does not correspond to any route can be sent by the CKMC to a quantum node in the network. The target quantum node performs the requested computational task and sends a reply message to the XOR unit 44. After acknowledging this message like any other reply message, the XOR unit 44 ignores the reply message generated by the target quantum node since the reply message identifier is not associated with any route in the lookup table T.

[0200] In a second example, a CKMC 40 configuration file contains a list of forbidden values. The CKMC 40 sends a command to the quantum node whose message identifier, which does not correspond to any route, is a multiple of one of the forbidden values. The quantum node has its own forbidden values, which are specified in a configuration file. Thus, if this node is compromised, the forbidden values ​​of other nodes are not revealed. The node then checks whether the message identifier in the received command is a multiple of one of its forbidden values. If so, the node calculates an elementary string by summing two software-generated random numbers, rather than from two of its quantum keys. The node transfers the result to the XOR 44 unit in a response message.After acknowledging it like any other reply message, the XOR 44 unit ignores this reply message since its identifier is not attached to any route.

[0201] Although the first example has a better level of security, the second example avoids wasting quantum keys.

[0202] In the event of interception of such a fictitious exchange, the attacker has no certainty about the relevance of the content of the intercepted message.

[0203] Dummy exchanges can also be carried out between the CKMC 40 and inactive nodes of the network. Such "stuffing" makes it possible to mask from a potential attacker the usage patterns of the quantum network, such as the transfer of the transport key at the same time of day between two users.

[0204] In a third variant, communications between the centralized key manager 40 and the user nodes Alice and Mike are advantageously The data is encrypted, as sensitive information is exchanged, such as the route request, the transport key to be exchanged, the global key, and any metadata. The centralized key manager 40 therefore shares a first security key with Alice and a second security key with Mike. The sharing of security keys between these infrastructure components is carried out in accordance with best practices.

[0205] In a fourth variant, other architectures are conceivable. For example, the XOR unit is independent of the centralized key manager 40. It could then be an additional feature of a quantum node or an independent unit. For example again, the XOR unit could be co-located with the Mike node.

[0206] The embodiment described in detail above proposes a certain division of tasks between the manager 52 and the controller 50, but other divisions are possible. In particular, the map update can be performed by the manager and / or the controller 50 and / or the CKMC 40. Alerts from the nodes are then routed to the components that require them. Benefits

[0207] The centralized key management module constitutes a particular implementation conforming to the standard, in particular ITU-T Recommendation Y.3803, especially in its version approved on 29 November 2023.

[0208] The centralized key management module allows the optimization of the transfer of transport keys on a quantum network by simultaneously querying the quantum nodes of the route chosen for the calculation of the global chain.

[0209] Indeed, the sequencing of commands according to the prior art leads to a slow transfer of transport key, which increases the risk of rerouting due to a failure affecting the components of a segment of the initially selected route, or the risk of collision between transfers of transport keys taking the same path, since sequencing does not allow several requests to be processed simultaneously.

[0210] On the contrary, with the present invention several transport key transfer requests can be taken into account simultaneously.

[0211] In addition, the centralized key management module, interfacing between the quantum nodes and the quantum network controller, increases the robustness and confidentiality of exchanges.

[0212] Indeed, according to the prior art, the XOR node is unable to verify the authenticity and / or integrity of the computational elements transmitted to it by the various quantum nodes. Under these conditions, a flow analysis makes it possible to determine the path taken by the transport key to be shared. With the invention, the XOR unit of the centralized key management module is adapted to verify the computational elements received from quantum nodes, using the route identifier, or the message identifier.

[0213] Centralized management of metadata saves the use of transport keys, which would otherwise be required to encrypt this metadata.

Claims

1. Demands Method (100) of exchanging an application key (Ko) in a communication infrastructure (1), the communication infrastructure comprising a "quantum" communication network implementing a quantum key distribution mechanism, or QKD network (2), the QKD network (2) comprising a plurality of quantum nodes (30;), two quantum nodes linked on the quantum network being connected by a quantum channel whose two interfaces, respectively hosted by each of the two quantum nodes, are adapted to generate and share at least one quantum key, said quantum key being saved in a local database of each of said two quantum nodes, characterized in that, the QKD network (2) further comprising a controller (50) adapted to define a route on the QKD network (2), a centralized key manager (40) and a computing unit, or "XOR unit" (44), the various components of the QKD network being connected to a "classical" communication network (3), the method comprises the steps of:; - each time a key is modified in the local database of a quantum node, transmission, by said quantum node, to the centralized key manager (40), of a set of information associated with the modified key, the set of information including an identifier of the modified key and a size of the modified key, and, if the modified key is a quantum key, an identifier of the interface of the quantum node which is associated with the modified key, and storage, by the centralized key manager (40), of the set of information in a central database (45); - following the receipt, by the controller (50), of a route request containing a required application key size, an identifier corresponding to a sending quantum node (300) and an identifier corresponding to a receiving quantum node (30n), determination (116), by the controller (50), of a route on the QKD network between the sending quantum node (300) and the receiving quantum node (30n), via a plurality of relay quantum nodes (30i to 30ni), and transmission of the determined route to the centralized key manager (40), the route being identified by a route identifier and corresponding to an ordered list of channel interfaces quantum between quantum nodes which allow to link the emitting quantum node (3Oo) and the receiving quantum node (30n), said interfaces being associated with quantum keys whose size is adapted to the required size of application key; - selection of the application key by the centralized key manager (40) in the central database according to the application key size, from among the keys associated with the issuing quantum node present in the central database, and indication to the issuing quantum node of the selected application key (Ko); - generation of a command (Ci), by the centralized key manager (40), for each of the quantum nodes of the route, the command for the sending quantum node, respectively the receiving quantum node, giving the identifier of a quantum key shared with a first relay quantum node, respectively a last relay quantum node, along the route, and the command for an ith relay quantum node giving the identifier of a quantum key shared with the previous quantum node and the identifier of a quantum key shared with the next quantum node, along the route, each command further integrating a message identifier corresponding to the route identifier, the keys of the commands being selected by the centralized key manager (40) in the central database (45) taking into account the route determined by the controller (50) and the application key size; - sending (130), in parallel, to each of the quantum nodes of the route, the corresponding command; - summation (140), by the ith quantum relay node, of the two quantum keys whose key identifier appears in the received command, to obtain an elementary string, and for the transmitting quantum node, of the quantum key whose key identifier appears in the received command and the application key, and sending a response to the XOR unit (44) containing the elementary string resulting from the summation and the message identifier; - calculation (150), by the XOR unit (44), of a global chain (K) by summing the elementary chains received from each of the quantum relay nodes (300) and the quantum transmitter node (300) which are associated with the route according to the message identifier; - transmission (160), by the XOR unit (44), of the global chain (K) to the recipient quantum node (30n); - extraction (170), by the recipient quantum node (30n), of the application key (Ko), by summing the global chain (K) and the quantum key (Kn) indicated in the command received from the centralized key manager.

2. A method according to claim 1, further comprising, for initiating the exchange of an application key (Ko): - transmission, by a first application, to the sending quantum node (3Oo), of a request to exchange an application key to a second application, comprising an identifier of the second application, and the size of the application key; - transmission, by the sending quantum node (3Oo), to the centralized key manager (40), of a request comprising an identifier of the sending node, an identifier of the second application and the size of the application key; - transmission, by the centralized key manager (40), to a manager (52) of the QKD network (2), of a request to identify the destination node associated with the second application;and, - transmission, by the centralized key manager (40), to the controller (50) of a request to calculate a route containing the identifier of the sending quantum node, an identifier of the receiving quantum node, and the application key size.;

3. A method according to any one of claims 1 to 2, wherein the centralized key manager (40): - develops a lookup table associating a plurality of message identifiers with the route identifier; - transmits the lookup table to the XOR unit (44); and, - generates a command to a particular quantum node of the route by incorporating a message identifier selected from the plurality of message identifiers, the response from a particular quantum node including said message identifier, and the XOR unit (44) determining the route corresponding to the response received from the message identifier and the lookup table, the XOR unit (44) summing the elementary keys associated with the same route identifier.

4. A method according to claim 3, wherein the centralized key manager (40) further performs fictitious exchanges with quantum nodes of the QKD network (2), by issuing commands whose message identifier is fictitious and is not associated with any route identifier in the lookup table.

5. A method according to claim 4, wherein a dummy message identifier is selected so as to be identified as such by the quantum node receiving the command, said quantum node then generating two randoms and transmitting the sum of these two randoms as an elementary key in the response sent to the XOR unit (44).

6. A method according to any one of claims 1 to 5, wherein the centralized key manager (40) generates metadata during the exchange of the application key (Ko) and shares said metadata with the sending quantum node and / or the receiving quantum node.

7. Communication infrastructure (1) adapted for implementing a method for exchanging an application key according to any one of claims 1 to 6, comprising a "quantum" communication network implementing a quantum key distribution mechanism, or QKD network (2), the QKD network (2) comprising a plurality of quantum nodes (30i), two quantum nodes linked on the quantum network being connected by a quantum channel whose two interfaces, respectively hosted by each of the two quantum nodes, are adapted to generate and share at least one quantum key, said quantum key being stored in a local database of each of said two nodes, the QKD network (2) further comprising: - a controller (50) of the QKDN network (2), adapted to calculate a route as a function of an application key size, between a sending quantum node (3Oo) and a receiving quantum node (30n);- a centralized key manager (40), interfacing between the quantum nodes and the controller (50), maintaining a central database (45) storing a set of information for each key present in each local database of each quantum node of the QKD network (2), the set of information comprising at least an identifier and a size of the corresponding key; and, - a computation unit or XOR unit (44); the different components of the communication infrastructure being connected via a "classic" communication network (3).

8. Centralized key manager (40) adapted to be integrated into a communication infrastructure according to claim 7.

9. Centralized key manager (40) according to claim 8, wherein the XOR unit (40) is a feature of the centralized key manager (40).

10. Product computer program comprising instructions which, when executed by a computer, enable the implementation of the steps, associated with a component of the infrastructure of claim 7, of a method according to any one of claims 1 to 6.

Images