Method and system for key distribution in a communication system

Abstract

Provided is a method for key distribution in a communication system comprising a source node, at least one intermediate node, and at least one destination node. The method comprises receiving a request for distributing a key to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node. Furthermore, the method comprises distributing the key from the source node to the at least one destination node based on the policy requirement. A report is transmitted, the report providing feedback regarding the key distribution based on the policy requirement.

Description

[0001] 271 032 s3 / s26 / sca

[0002] METHOD AND SYSTEM FOR KEY DISTRIBUTION IN A COMMUNICATION SYSTEM

[0003] TECHNICAL FIELD

[0004] The present invention relates to the field of key distribution in a communication system.

[0005] BACKGROUND

[0006] Key distribution systems are used to produce secret keys and share them among different sites . These shared keys, examples of shared secrets, may be cryptographic keys used to encrypt and decrypt messages . Often, key distribution is based on public key cyphers, wherein complex mathematical calculations requiring a vast amount of computing power to crack are used. Another option is quantum key distribution (QKD) which uses a quantum system that relies on basic and fundamental law of nature to protect data .

[0007] For example, QKD systems enhance the confidentiality and integrity of these secret keys while sharing the secret keys out-of-band, i . e . out of the transmission segment used to carry user data . This means that the QKD system may use a second channel independent from a channel used to transport user data, as opposed to technologies such as Diffie-Hellman algorithms where a symmetric key is generated in-band. The technology of QKD systems relies on quantum physic principles that are limited to the photonic domain. Therefore, as soon as the communication exits photonic domain to implement computing tasks on a shared secret, e . g. key encryption, key storage, or the like, a proof of security has to be demonstrated through a combination of security controls in the electronic domain, for example .For traditional Internet Protocol ( IP) traffic, the SCION (Scalability, Control, and Isolation On Next-Generation Networks) routing technology is available . However, the IP routing protocol enhanced by SCION and key distribution protocols are different in various aspects . Thus, the IP routing protocols cannot be simply used for key distribution systems . For example, the following is noted with respect to the IP routing concept :

[0008] - A single user plane made of routing nodes to implement the service is required.

[0009] - A beacon mechanism is required to implement autodiscovery of a path.

[0010] - Paths can be discovered constantly through signalization messages . Path servers are available to learn and constantly maintain knowledge of the network topology. - The IP routing concept uses concepts similar to Domain Name System (DNS) in order to name servers .

[0011] In contrast thereto, the following is noted with respect to a key distribution concept of a QKD system, as an example for a key distribution system:

[0012] - A combination of QKD layers and key management system (KMS) layers to implement a service is required. The QKD layers and the KMS layers form part of a quantum communication infrastructure (QCI ) , wherein the QKD layer is used to generate quantum keys and the KMS layer is used to perform cryptographic functions to protect keys and transmit protected keys over a transport network that can be public . The QKD layer and KMS layer are serving the user plane through an interface, so they are included in a routing concept to deliver a key to the user plane .

[0013] - The provisioning of QKD nodes requires a strong authentication mechanism between every pair of QKD nodes . This means that no auto-discovery mechanism is possible, because auto-discovery implicitly considers a mechanism where there is no intervention to declare anode . Here, because it is required to declare pre-shared keys on a QKD node to be authenticated by its QKD neighboring nodes, an intervention is required to load the pre-shared key. This intervention requires security control to protect the confidentiality of the pre-shared keys at the level of quantum-safe cryptography, so there is currently no standard tackling this issue and ensuring auto-discovery. Thus, at the KMS layer, a quantum communication infrastructure (QCI ) operator, also called QKD operator, is expected to have a clear asset database to implement cyber security operations; there are currently no auto-discovery mechanism described in the QKD technology domain.

[0014] - Paths are not discovered but are fairly static or computed from resources available through several nodes . Paths in the QKD layer have to be declared during provisioning and are not dynamic . Paths in the KMS layer are dynamically defined by a request for pairwise key sharing among a pool of QKD nodes (terrestrial or space QKD nodes) should no key encryption-key be available on the QKD node identified for the solution and an amount of quantum keys pre-existing in a local key store of a relay node at the moment of a user request . A secret key shared among these nodes are used to perform the key distribution function hop-by-hop .

[0015] - A concept similar to DNS is not clearly defined. It can be assumed that the nature of such a service requires a mechanism to declare new nodes in a more secured way than DNS entries and propagation. The list of nodes is in essence a sensitive asset that might not be shared among QKD systems .

[0016] Until now, the key distribution mechanism is not standardized, while the SCION protocol is a more mature concept that has been implemented and is providing connectivity services . Due to the differences in the complexity of IP routing concepts and key distribution, it isnot possible to simply use the IP routing concepts also for key distribution.

[0017] Thus, there are currently no solutions for key distribution providing adequate security control when sharing a key via a key distribution system. The lack of adequate security control in key distribution may lead to reduced trustworthiness of a key routing function performed by an operator, such as a QKD operator . Furthermore, security incidents cannot be detected, and therefore cannot be rectified, which leads to a generally lower level of security in key distribution.

[0018] SUMMARY

[0019] It may be an obj ect of the invention to provide methods and systems for improving the level of security in key distribution and ensuring adequate security control .

[0020] According to an aspect, a method for key distribution in a communication system comprising a source node, at least one intermediate node, and at least one destination node is provided. The method comprises receiving a request for distributing a key to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node . Furthermore, the method comprises distributing the key from the source node to the at least one destination node based on the policy requirement . A report is transmitted, the report providing feedback regarding the key distribution based on the policy requirement .

[0021] According to another aspect, a system for key distribution comprising a source node, at least one intermediate node, and at least one destination node is provided. The source node is configured to receive a request for distributing a key to theat least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node . The key is distributed from the source node to the at least one destination node based on the policy requirement . A report is transmitted, the report providing feedback regarding the key distribution based on the policy requirement .

[0022] According to another aspect, a computer program is provided. The computer program comprises instructions which, when the program is executed by a computer, cause the computer to carry out the step of receiving a request for distributing a key, in a communication system comprising a source node, at least one intermediate node, and at least one destination node, to the at least one destination node . The request includes a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node . The computer is further caused to carry out the steps of distributing the key from the source node to the at least one destination node based on the policy requirement and transmitting a report . The report provides feedback regarding the key distribution based on the policy requirement .

[0023] According to another aspect, a computer-readable medium is provided. The computer-readable medium comprises instructions which, when executed by a computer, cause the computer to carry out the step of receiving a request for distributing a key, in a communication system comprising a source node, at least one intermediate node, and at least one destination node, to the at least one destination node . The request includes a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node . The computer is further caused to carry out the steps of distributing the key from the source node to the at least one destination node based on thepolicy requirement and transmitting a report . The report provides feedback regarding the key distribution based on the policy requirement .

[0024] According to another aspect, a node for key distribution in a communication system is provided. The node may be the source node mentioned above . The node is configured to receive a request for distributing a key to at least one destination node . The request includes a policy requirement for distributing the key from the node via at least one intermediate node to the at least one destination node . The key is distributed to the at least one destination node based on the policy requirement and a report is generated in the communication system. The report provides feedback regarding the key distribution based on the policy requirement .

[0025] According to another aspect, a method performed by a node in a communication system for key distribution is provided. The node may be the source node mentioned above . The method comprises receiving a request for distributing a key to at least one destination node, the request including a policy requirement for distributing the key from the node via at least one intermediate node to the at least one destination node . The key is distributed to the at least one destination node based on the policy requirement and a report is generated in the communication system. The report provides feedback regarding the key distribution based on the policy requirement . Furthermore, a computer program and a computer-readable medium for causing a computer to carry out the method are provided.

[0026] According to another aspect, a node for key distribution in a communication system is provided. The node may be the at least one intermediate node mentioned above . The node is configured to receive a key, the key being distributed based on a policy requirement for distributing the key from a source node via the node to at least one destination node .The key is distributed to the at least one destination node based on the policy requirement and a report is generated in the communication system. The report provides feedback regarding the key distribution based on the policy requirement .

[0027] According to another aspect, a method performed by a node in a communication system for key distribution is provided. The node may be the at least one intermediate node mentioned above . The method comprises receiving a key, the key being distributed based on a policy requirement for distributing the key from a source node via the node to at least one destination node . The key is distributed to the at least one destination node based on the policy requirement and a report is generated in the communication system. The report providing feedback regarding the key distribution based on the policy requirement . Furthermore, a computer program and a computer-readable medium for causing a computer to carry out the method are provided.

[0028] According to another aspect, a node for key distribution in a communication system is provided. The node may be the at least one destination node mentioned above . The node is configured to receive a key, the key being distributed based on a policy requirement for distributing the key from a source node via at least one intermediate node to the node . A report is generated in the communication system, wherein the report provides feedback regarding the key distribution based on the policy requirement .

[0029] According to another aspect, a method performed by a node in a communication system for key distribution is provided. The node may be the at least one destination node mentioned above . The method comprises receiving a key, the key being distributed based on a policy requirement for distributing the key from a source node via at least one intermediate node to the node . A report is generated in the communicationsystem, the report providing feedback regarding the key distribution based on the policy requirement . Furthermore, a computer program and a computer-readable medium for causing a computer to carry out the method are provided.

[0030] BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG. 1 shows a flowchart of a method for key distribution in a communication system according to an embodiment .

[0032] FIG. 2 shows a schematic diagram of a functional architecture model of a quantum key distribution network according to an embodiment .

[0033] FIG. 3 shows a schematic diagram of a key distribution in a quantum key distribution system according to an embodiment .

[0034] FIG. 4 shows a schematic diagram of an example of a space quantum communication infrastructure performing an end-to-end key distribution.

[0035] FIG. 5 shows a schematic diagram of an example of a simplified space quantum communication infrastructure performing an end-to-end key distribution.

[0036] FIG. 6 shows a schematic diagram of a communication system for key distribution according to an embodiment .

[0037] DETAILED DESCRIPTION

[0038] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings . Other embodiments, however, are contained within the scope of the subj ect matter disclosed herein, the disclosed subj ect matter should not be construed as limitedto only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subj ect matter to those skilled in the art .

[0039] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc . are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc . , unless explicitly stated otherwise . The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where a step must necessarily follow or precede another step due to some dependency. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate . Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa . Other obj ectives, features, and advantages of the enclosed embodiments will be apparent from the following description .

[0040] FIG. 1 shows a flowchart of a method for key distribution in a communication system according to an embodiment . The communication system may be a terrestrial or satelliteterrestrial network, wherein the communication may be over satellite and / or terrestrial . The communication system may comprise a plurality of network nodes, such as a source node, at least one intermediate node, and at least one destination node, wherein the source node may be an initiator of a routing request and may also be called "initiator node" . Thus, a user, such as a customer, a key consumer, or third-party operator of the communication system, may place the request for key distribution at the source node, wherein the user may define policy requirements for the key distribution.The at least one intermediate node may be connected to the source node and the at least one destination node to relay the key to be distributed from the source node to the at least one destination node . Relaying or distributing the key may comprise forwarding the key until the key reaches its destination, such as the at least one destination node .

[0041] The at least one destination node may be a node destined or determined to receive the key, wherein the at least one destination node may be identified by the source node in the routing request using a unique identification, such as a universally unique identifier (UUID) , for example . The key is an example of a shared secret which should be shared, i . e . distributed, in the communication system in a secure way. The at least one destination node may communicate with a user who is destined to receive the key.

[0042] For example, the communication system is a quantum key distribution (QKD) system. This means that the key may be distributed over a QKD system. The QKD system may be a quantum communication infrastructure (QCI ) domain. In order to securely distribute the key over the QKD system, the key may be wrapped, e . g. combined, using a quantum key (QKey) , wherein the wrapped key may be distributed between QKD nodes . An aim is that the key is not modified or otherwise manipulated when being transported end-to-end. The at least one destination node may unwrap the wrapped key in order to obtain the key using its respective quantum key.

[0043] The quantum key may be a cryptographic sequence of random bits of defined length, complemented by metadata, such as a header to manage its life cycle, whose entropy may rely on quantum physic principles and which may be generated and shared with technology that follows quantum principles to protects its confidentiality. The quantum key may have the same length as or a longer length than the key to be distributed in order to be able to wrap the key with the quantum key. In order to perform the wrapping, an XORoperation between the key and the quantum key may be performed. However, this is not limiting, and any other suitable operation than an XOR operation, such as an extended XOR operation or XNOR operation, may be performed to combine the key with the quantum key.

[0044] The QKD system, such as a QCI domain, may be a system, be it a terrestrial network or a space-based network, such as a satellite-terrestrial network, interconnecting and managing QKD nodes to offer service such as quantum key generation and quantum key sharing between distant QKD nodes . The entity responsible for operating and maintaining the QKD system may be a QCI operator, wherein the scope of operation may encompass quantum key operations, network operations, such as connectivity between QKD nodes, cyber security operations, and the like .

[0045] A QKD node may implement interfaces to deliver such services and may be a site gathering at least one instance of QKD module, key manager, and quantum key distribution network (QKDN) controller, see also the document ITU-T Y.3811, https : / / www . ietf . org / lib / dt / document s / LIAISON / liai son-2023-01-2 4-itu-t-sg-13-opsawg-ls-on-work-progress-on-quantum-key-distribution-qkd-network-in-sgl3-as-of-november-2 022-attachment-16.pdf . The key manager may comprise a software and / or hardware instance, such as a key management entity (KME) , also called key management system (KMS) . If the communication system is a QKD system, the above-mentioned source node, the at least one intermediate node, and the at least one destination node may be QKD nodes .

[0046] According to an example, the "key distribution" may be a "key delivery" or a "key relay" . The "key distribution" may be also called "key sharing" . For example, the key delivery is a quantum computing resistant key delivery, leveraging satellite-based and / or terrestrial-based quantum random number generator (QRNG) to generate and transport user keys,such as from a service provider, over long distance . Entropy level may lie with the service provider . For example, the key relay is a quantum computing resistant key relay, leveraging satellite-based and / or terrestrial-based QRNG to protect and transport user-provided keys, such as customer-provided key, over long distance . The entropy level may be the responsibility of the customer .

[0047] A functional architecture model of a QKDN is illustrated by way of example in FIG. 2, wherein FIG. 2 is an extract from ITU-T Y.3811 and can be also found in ITU-T Y.3802 ("Quantum key distribution networks - Functional architecture") . It is further referred to ITU-T Y.3810 ("Quantum Key distribution network interworking - Framework") for further information on QKD architecture .

[0048] It is noted that even though a QKD system is described in detail, the communication system is not limited to a QKD system, and any type of communication system can be used for distributing a key from a source node to a destination node .

[0049] Returning to FIG. 1, the method for key distribution may comprise receiving (Slid) a request for distributing a key to the at least one destination node . For example, a user, such as a customer, key consumer, or third-party operator of the communication system, may place a request at the source node . The request may include a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node . Based on the policy requirement, the key may be distributed (S120 ) from the source node to the at least one destination node . Here, the expression "based on the policy requirement" is synonymous to, and can be replaced with, "in accordance with the policy requirement", "as per the policy requirement", or "according to the policy requirement" . It should be ensured that the policy requirement is fulfilled when distributing, i . e . routing the key from the source node via the at leastone intermediate node to the at least one destination node . Thus, the user can provide instructions that the key distribution is to be performed according to the policy requirement . In order to place a request by the user at the source node, a physical connectivity to the source node may be established.

[0050] The policy requirement may be a rule, such as a baseline security policy requirement (i . e . , a reference security policy requirement) or a baseline confidentiality requirement (i . e . , a reference confidentiality requirement) , indicating the requirements to distribute the key from the source node via the at least one intermediate node to the at least one destination node . According to an embodiment, for distributing the key to the at least one destination node, a route to distribute the key may be computed based on the policy requirement . The route may include the source node, the at least one intermediate node, and the at least one destination node, wherein the at least one intermediate node may receive and forward the key intended for the at least one destination node . By considering the policy requirement when computing the route, it is ensured that only the nodes, such as trusted nodes, that are allowed to receive and distribute the key are included in the route . Thus, the user control on the key distribution is improved by implementing a policy requirement .

[0051] For example, the policy requirement includes at least one of a definition of the at least one destination node for receiving the key, a definition of the at least one intermediate node for distributing the key, a definition of an exclusion zone through which the key is prohibited to transit, a definition of a classification of the key to be distributed, and the like .

[0052] The definition of the at least one destination node and / or the at least one intermediate node may compriseidentifications with which a destination node, a group of destination nodes, an intermediate node, and / or a group of intermediate nodes, that should receive and / or distribute the key, can be determined. For example, unique identifications, such as UUIDs, are used to identify the at least one destination node and the at least one intermediate node . According to an example, the definition of the at least one destination node and / or the at least one intermediate node may be a definition of software and / to hardware instances executing the key distribution. For example, in a QKD system, the definition of the at least one destination node and / or the at least one intermediate node is a definition of a KME or a group of KMEs that shall receive the key. Thus, by defining the at least one destination node and / or the at least one intermediate node with the policy requirement, nodes can be excluded from receiving the key, ensuring that only the desired nodes, such as trusted nodes, participate in the key distribution.

[0053] The defined exclusion zone may comprise a plurality of nodes, wherein these nodes, such as intermediate nodes and / or destination nodes, may not be used to forward and / or receive the key. Thus, by defining an exclusion zone, nodes belonging to this exclusion zone may not be used in the key distribution .

[0054] For example, the definition of an exclusion zone, through which the key is prohibited to transit, is a definition of a geographic zone or a list of nodes through which the key should not transit . As an example, a geographic zone is encompassed where a legal framework applied to data confidentiality may not match an expectation of a user requesting to distribute the key. Thus, there may be a possibility to exclude some nodes, such as QKD nodes in a QKD system, from being intermediate nodes manipulating the key to be distributed.For instance, it may not be desired to select a node in a territory under jurisdiction that allows a state to have access to all communication passing through this infrastructure . This may be applicable to terrestrial extension of a space QCI which is mainly a star topology with only one hop after a satellite . By defining an exclusion zone, the key may only be distributed to intermediate and / or destination nodes outside of the exclusion zone, such as intermediate nodes and / or destination nodes not belonging to the exclusion zone . Therefore, it is possible to effectively and quickly exclude nodes from key distribution.

[0055] The definition of a classification of the key to be distributed may comprise a definition of a protection level or classification level of the key to be distributed. For example, the key is not distributed to an intermediate node and / or a destination node not meeting the definition of the classification. As an example, the source node meets a classification level A and a node, such as an intermediate node and / or a destination node, requested by the request for distributing the key does not meet classification level A. In this example, the requested node not meeting classification level A is excluded from key distribution.

[0056] As explained above, the policy requirement may provide a possibility to define confidentiality requirements applied to key distribution, such as a key routing function. The confidentiality requirements may comprise an identification of nodes involved in the key distribution, an isolation principle of group of nodes to exclude nodes from the distribution, and / or a definition of a classification level to be met by the nodes participating in the key distribution, for example . The confidentiality requirements may further comprise a level of security, a maximum number of hops in the key distribution, age of keys, key cost ( for example, satellite keys, i . e . keys generated at satellite nodes, may be much more "precious" than terrestrial keys, i . e . keysgenerated at terrestrial nodes) , time to recover or replenish the keys used, exclusion of terrestrial or satellite nodes, epsilon security, or the like .

[0057] It is possible that the policy requirement includes contradicting requirements . For example, the policy requirement comprises a unique identification of an intermediate node which, at the same time, is included in an exclusion zone . If the policy requirement includes such contradicting requirements, the respective request including this contradicting policy requirement may be rej ected. However, it is also possible to implement measures to resolve such contradictions . For example, to resolve such contradictions, it is possible to prioritize items in the policy requirement . For instance, the requirement of an exclusion zone may be prioritized over unique identifications . Thus, nodes listed in exclusion zones may not receive and distribute the key even if their unique identifications are indicated in the policy requirement .

[0058] Returning to FIG. 1, the method for key distribution may further comprise transmitting (S130) a report, the report providing feedback regarding the key distribution based on the policy requirement . The report may provide feedback regarding a state of the key distribution operation in order to indicate potential risks or to indicate the absence of risks . For example, the report indicates whether the policy requirement has been fulfilled when distributing the key. Furthermore, it can be determined based on the report whether a security incident has occurred during the key distribution. For example, the report is transmitted, by each of the intermediate node and the destination node, to the source node to inform the source node whether the policy requirement is fulfilled. It is also possible that a report may be sent to the at least one destination node to inform the at least one destination node whether the policy requirement is fulfilled. If it is detected that the policy requirement hasnot been fulfilled, the at least one destination node and / or the at least one source node may discard the key, because the at least one destination node and / or the at least one source node may assume that the key has been manipulated, i . e . compromised or tampered with, for example . Thus, based on the report, a proof of the policy requirement being applied or not can be provided.

[0059] FIG. 3 shows a schematic diagram of a key distribution in a QKD system 300 according to an embodiment . Again, it is noted that the communication system is not limited to a QKD system, and any other system for key distribution may be used. For further details regarding key distribution in a QKD system, it is also referred to ITU-T Y.3802, for example .

[0060] The QKD system 300 may comprise a source node 320, also called QKD node A at site A, an intermediate node 330, also called QKD node B at site B, and a destination node 340, also called QKD node C at site C . The number of intermediate nodes and destination nodes is not limited to the nodes shown in FIG. 3, and the number of intermediate nodes and the number of destination nodes may be greater than 1.

[0061] Furthermore, the QKD system 300 may comprise a software-defined networking (SDN) orchestrator 310 (note : the SDN orchestrator 310 may also be implemented partially or completely in hardware) to dynamically allocate network resources, manage network security policies, and optimize network performances . The SDN orchestrator 310 may be the management layer of the QKD system 300. For example, the SDN orchestrator 310 checks the feasibility of the key distribution request (described further below) and computes a route to transfer the key 350 to the destination node 340 according to the policy requirement .

[0062] In the QKD system 300, quantum key routing may be performed, wherein quantum key routing may be defined as key relayimplemented hop-by-hop between pairs of QKD nodes, such as between QKD node A and QKD node B and between QKD node B and QKD node C . The QKD nodes A, B, and C may generate quantum keys KeyAlBl and KeyBICl point-to-point over a respective quantum channel (labelled "Q chan" in FIG. 3) , such as for example over a free-space optical channel and using the BB84 protocol, and may store the resulting quantum keys KeyAlBl and KeyBICl locally. In FIG. 3, the key to be distributed from the source node 320 (QKD node A) to the destination node 340 (QKD node C) via the intermediate node 330 (QKD node B) is the key 350, also called "key U99" . The key 350 may be provided by a user U99 (not shown) requesting key distribution or may be generated locally, e . g. by a quantum random number generator (QRNG) . In order to securely transmit the key 350 and protect the key 350 until the end of the chain, such as until the destination node 340, the key 350 may be combined, by the QKD nodes A and B, with the quantum keys KeyAlBl and KeyBICl . Thus, the key 350 may be encrypted and decrypted with the quantum keys in order to ensure that the key 350 is neither modified nor eavesdropped during the key distribution, wherein the key exchanges may be further authenticated. It is further noted that a signalization channel (labelled "signalisation" in FIG. 3) may be used to transport a message for a post-processing protocol, such as the BB84 protocol, to be performed after enough measurements of quantum bits have been buffered.

[0063] In more detail, the QKD node 320 may receive a request for distributing the key 350, wherein the request may include a policy requirement for distributing the key from the QKD node 320 via the QKD node 330 to the QKD node 340. For example, the route for the key distribution is calculated by the SDN orchestrator 310 based on the policy requirement . The policy requirement may indicate the intermediate node to be used for distributing the key 350 and / or the destination node which should receive the key 350. For example, the KMS U99 of the source node 320 places the request for key distributiontogether with an exchange of its own key. Thus, key routing may be requested to reach the KMS User 50 (U50) of the QKD node 340.

[0064] The control link (labelled "Ctrl link" in FIG. 3) of the QKD node 320 may be used to place the request . The data link (labelled "Data link" in FIG. 3) of the QKD node 320 may be used to communicate with KMS Al of the QKD node 320 in order to push the key 350 to the KMS Bl of the QKD node 330. In order to generate the quantum key A1B1 at both the QKD node 320 and the QKD node 330, the QKD node 320 and the QKD node 330 may be instructed to generate the quantum key A1B1 using their pair of QKD modules Alice Al and Bob Bl over a quantum channel (labelled "Q chan" in FIG. 3) . It is further noted that the interface labelled "sig" in FIG. 3 (which stands for "signalization") may be used for acknowledgment on a correct key reception / forward . It may be used for synchronizing the respective KMS (such as KMS Al and KMS Bl, or KMS Bl and KMS Cl ) end-to-end on a key life-cycle .

[0065] In order to generate the quantum key B1C1 at both the QKD node 330 and the QKD node 340, the QKD node 330 and the QKD node 340 may be instructed to generate the quantum key B1C1 using their pair of QKD modules Alice Bl and Bob Cl over another quantum channel (also labelled "Q chan" in FIG. 3) . In the end, quantum keys A1B1 and B1C1 may be made available to the respective KMS . For example, the quantum key A1B1 is made available to KMS Al and KMS Bl, and the quantum key B1C1 is made available to KMS Bl and KMS Cl . It is also referred, for example, to the BB84 protocol, proposed by Charles Bennett and Gilles Brassard in 1984, for further details on generating the quantum keys . The BB84 protocol is a quantum key distribution (QKD) protocol that may be used for example for long distance (about 100km) between two endpoints, e . g. Alice and Bob . The BB84 protocol is a discrete variable approach that primarily uses polarization states of photons to encode information. However, it can be modified to usephase encoding as well . Alternative prepare-and-measure approaches may be used based on continuous variable (CV) transmission in the prepare and measure domain of QKD, which may operate within 20km range . It is also possible that the quantum keys or other keys to encrypt and decrypt the key 350 are generated and stored beforehand. For example, a peer-to-peer (p2p) link may create as many keys as possible to be used for encryption and decryption. For a star topology network, an orchestrator of the star topology network may perform the generation of such keys .

[0066] In order to securely distribute the key 350, the key 350 to be distributed may be wrapped using a quantum key, the wrapped key being distributed from the QKD node 320 via the QKD node 330 to the QKD node 340. The quantum key may be a cryptographic sequence of random bits, having a defined bit sequence length. The quantum key may be generated in the operational scope of the serving QCI . The destination node 340 may unwrap the wrapped key using the quantum key in order to obtain the key 350 to be distributed.

[0067] For example, for wrapping the key 350, the respective quantum keys A1B1, B1C1 stored in the source node 320 and the at least one intermediate node 330 may be used for wrapping, wherein the at least one QKD node 340 may use its respective quantum key B1C1 stored in the QKD node 340 for unwrapping the wrapped key. For instance, the QKD node 320, specifically KMS Al of QKD node 320, may wrap the key 350 with the quantum key A1B1 to obtain a wrapped key 350a . This wrapped key 350a may be transferred over a classical, i . e . non-quantum, network, such as a traditional Internet Protocol ( IP) network, to the QKD node 330, specifically KMS Bl of the QKD node 330. The QKD node 330, specifically KMS Bl, may unwrap the key 350a using its copy of the quantum key A1B1 to obtain the key 350. In order to transfer the key 350 to the QKD node 340, the QKD node 330, specifically KMS Bl, may wrap the key 350 with the quantum key B1C1 and may transfer the wrappedkey 350b to the QKD node 340, specifically KMS Cl of the QKD node 340. The QKD node 340, specifically KMS Cl, may unwrap the wrapped key 350b using its copy of the quantum key B1C1 in order to obtain the key 350. The key 350 may be delivered over the data link to KMS U50. Thus, the key distribution in QKD system 300 is completed. It is also possible to reverse the order for wrapping the keys, such that key 350 may not be stored in clear text in a storage unit of the at least one intermediate node . For example, the QKD node 330, specifically KMS Bl, may first wrap the key 350a with the quantum key B1C1 and then unwrap it with the quantum key A1B1 . This may further increase the security on the keys, because the key 350 is not stored in clear text at the intermediate node 330.

[0068] According to an example, in order to wrap and unwrap the key 350 with the respective quantum key, an XOR operation on the key 350 may be performed. However, this is not limiting and any other suitable operation than an XOR operation may be performed for combining the key 350 with the respective quantum key, such as extended XOR or XNOR operations .

[0069] It is further noted that the key 350 can be provided by the user requesting the key distribution, wherein the user may be entitled to provide the key 350 by its own means, or can be provided by a QRNG. It may be advantageous that the key 350 has the same bit sequence length as, or preferably shorter bit sequence length than, the quantum keys A1B1 and B1C1 in order to successfully wrap the key 350 with each of the quantum keys . Thus, the quantum keys may have the same length as, or longer length than, the key 350. For example, a default standard bit sequence length of 256 bits for the key 350 may be chosen. However, this is not limiting, and the bit sequence length may be shorter or longer than 256 bits . For example, the user may place a request for key distribution service where the key length of the key chosen by the user may be a parameter included in the request . The KMS layer ofthe QCI operator may be performing necessary functions to arrange transport of the key 350 with the chosen key length.

[0070] As shown by way of example in FIG. 3, the source node 320, here QKD node A at site A, may be the initiator of key relay for the segment QKD node A and QKD node B . The intermediate node 330, here QKD node B at site B, may be the initiator of key relay for the segment QKD node B and QKD node C . The QKDN controller B of the intermediate node 330 may be the N-l controller on the routing path from the destination node 340 standpoint, whereas the QKDN controller A of the source node 320 may be the N-2 controller on the routing path from the destination node 340 standpoint . As explained above, with such a setup, it is possible to securely distribute the key 350 from the QKD node 320 via the QKD node 330 to the QKD node 340.

[0071] As mentioned above, the request for distributing a key may include a policy requirement for distributing the key from a source node via at least one intermediate node to at least one destination node . According to an embodiment, before distributing the key, the policy requirement may be checked to validate the feasibility of the key distribution based on the policy requirement . If it is not feasible to distribute the key based on the policy requirement, the request may be rej ected. Thus, the consistency of the request can be checked to answer the question of whether it is possible to distribute the key and fulfil the policy requirement at the same time . Therefore, it is ensured that the policy requirement is not violated, leading to increased trustworthiness in the key distribution.

[0072] In the example of the QKD system 300 shown in FIG. 3, the SDN orchestrator 310 may analyze the request based on the policy requirement . The SDN orchestrator 310 may validate the feasibility of the key routing service and, thus, the consistency of the request based on the policy requirementand may compute a route for key distribution if the request is not rej ected. If, however, it is not feasible to distribute the key based on the policy requirement, the SDN orchestrator 310 may rej ect the request .

[0073] For example, the policy requirement may comprise the requirement of excluding a specific satellite from the key distribution. If there are several satellites in a fleet, then the SDN orchestrator 310 may consider the request and compute a route to distribute the key without using the excluded satellite . However, if the specific satellite to be excluded is the only satellite available, then the SDN orchestrator 310 may need to rej ect the request, because key distribution without this specific satellite may not be feasible .

[0074] Another example of inconsistency resulting from a policy requirement may be if the policy requirement comprises a classification level for the key distribution service that is not matching a classification level of the asset within a QKD node planned to be involved. Again, the request may be considered to be not consistent and may therefore be rej ected. Thus, it may be anticipated that for certain levels of classification, a request might be rej ected should the asset expected to implement the solution would not meet the classification level definition. The classification level may be understood as a level of protection that needs to be fulfilled by a node to participate in the key distribution.

[0075] Another example of inconsistency resulting from a policy requirement may be if one node to be served does not exist . Again, the request may be rej ected due to the inability to fulfil the policy requirement .

[0076] As already mentioned above, a report providing feedback regarding the key distribution based on the policy requirement may be transmitted. The transmission of a reportmay be a possibility to provide reception of a proof that the policy requirements, such as confidentiality requirements, have been successfully implemented in the operation domain of a key distribution operator, such as a QKD operator, according to a user' s request of distributing a key based on the policy requirement .

[0077] According to an embodiment, the report may be transmitted, by the at least one intermediate node and the at least one destination node, to the source node . For example, each of the at least one intermediate node and each of the at least one destination node, that received the key, generates a report to be transmitted to the source node . Each generated report may include at least one of an alert on a deviation from the policy requirement when the key was distributed, an alert on a security incident, a cryptographic proof, and the like . Thus, the instance initiating the key distribution, such as KMS U99 in FIG. 3, may be provided with a key routing service including the reception of a report provided by the communication system of the effective conditions of the operation while delivering the service, such as key distribution .

[0078] In the example of FIG. 3, the QKD node 330 and the QKD node 340 may transmit a report to the QKD node 320. For example, a report may be self-generated along the contribution of every QKDN controller in the path, such as QKDN controller B and QKDN controller C in FIG. 3, and may be transmitted by the QKDN controllers B and C of the QKD nodes B and C to the QKD node A serving as the initiator of the request . Specifically, the receiver of the report may be KMS U99 of QKD node A.

[0079] A report including an alert on a deviation from the policy requirement may ensure that the user requesting key distribution receives an alert that the key distribution has deviated from the policy requirement, such as a security baseline policy, requested by the user . For example, if theuser defines an exclusion zone for the key distribution but receives a report from a node belonging to the exclusion zone, the report from the node may serve as an alert on a deviation from the policy requirement . For example, the SDN orchestrator may have incorrectly accepted or validated a request for key distribution, which may result in an alert being generated. An error in the key distribution resulting in an alert may furthermore be related to a modification of the security context of a given destination node, selected for the route by the SDN orchestrator . For example, a security incident (as described above) on that destination node may happen in between the moment the SDN orchestrator accepts the request for key distribution, calculates a path for the key distribution, and instructs controllers of the respective nodes involved in the key distribution to prepare a key routing path, and the moment the path gets ready for the final transmission by the source node . In such case, the security incident may be indicated in the report, wherein remediations can be implemented by the source node . Alerts may be also generated if a node is no longer considered secure . For example, a node can self-declare its insecurity in case physical manipulation of its hardware is detected, for example . Also, if it is assumed that a routing path is provided to each node, the nodes can further check if the routing path is maintained and can send an alert .

[0080] According to an example of a QKD system, the alert, generated by a KME or QKDN controller, may indicate an error or failure of the key routing and the outstanding value representative of a condition of the quantum channel (e . g. quantum bit error rate (QBER) ) at the moment quantum keys were in the process of distillation, as disclosed in ETSI GS QKD 016, VI . 1 . 1 ("Quantum Key Distribution (QKD) ; Common Criteria Protection Profile - Pair of Prepare and Measure Quantum Key Distribution Modules", see also

[0081] https : / / www . etsi . org / deliver / etsi_gs / QKD / 001_099 / 016 / 01.01.01 _60 / gs_QKD01 6v0101 Olp . pdf : it is referred to page 43, section"FAU_GEN. l Audit data generation", and page 46, section "FPT FLS . l / EoL Failure with preservation of secure state"

[0082] A report including an alert on a security incident may ensure that the user receives an alert if a node of the communication system, which participates in the key distribution, e . g. at least one intermediate node and at least one destination node, experiences a security incident . The security incident may be identified by a service provider of the communication system, such as a QKD service provider . For example, the alert on a security incident may refer to a security incident confirmed by a cyber security operation center upon a security event reported by a site QKDN controller, for example . For instance, a security incident may be detected by a signal of an unexpected open door on a rack hosting node equipment, e . g. QKD node equipment, by a failed integrity check in a software and / or hardware component within a node, such as a QKD node, etc . When the source node receives a report including an alert on a security incident, it may be up to a cyber security operation of the user or the communication system operator, e . g. the QCI operator, to trigger remediations . The benefit of such an automated reporting is that a user can benefit from high reactivity of alerting. A fast processing of security incident qualifications by cyber security operation tools can be supported.

[0083] It is noted that an alert about a security incident may be extended to a dissemination of a key revocation upon a compromission of a quantum key delivered previously by a QCI operator, for example, to a user placing a key distribution request . This feature may be defined with a data retention matching a user service level agreement (SLA) and the quantum key life expectancy defined during its instantiation.

[0084] A report including a cryptographic proof may indicate to the user that the distributed key has transitioned within anexpected path defined by the policy requirement . For example, if an exclusion zone has been defined by the user, the cryptographic proof may indicate to the user that no node belonging to the exclusion zone has received the key. For the cryptographic proof, the concept of blockchain may be used.

[0085] For example, the cryptographic proof is a digital signature generated respectively by the at least one intermediate node and the at least one destination node using private keys, wherein the source node uses corresponding public keys to verify the authenticity of each report . Therefore, the source node may be able to verify or prove the origin of each report . The concept of private and public keys is known in the field of public-key cryptography, or asymmetric cryptography, where pairs or related keys are used. Each key pair of a public key and a corresponding private key may be generated with known cryptographic algorithms, wherein the private key must be kept secret . Thus, each intermediate node and each destination node, which may generate a report including a cryptographic proof, may securely store a respective private key, wherein the source node may have access to the corresponding public keys . For example, a repository of public keys from all intermediate nodes and destination nodes may be provided in order to be able to verify the origin of the reports .

[0086] Instead of using public-key cryptography for the cryptographic proof, the digital signature may be based on shared secrets, the shared secrets being generated and distributed in a secure way, similar to symmetric cryptography. In such a case, the cryptographic proof may be a digital signature generated respectively by the at least one intermediate node and the at least one destination node using shared keys, and the source node uses the shared keys to verify the authenticity of each report . The expression "shared keys" may refer to keys shared between the sourcenode, the at least one intermediate node, and the at least one destination node beforehand.

[0087] To create a digital signature, the at least one intermediate node and the at least one destination node may sign the report using their respective private keys or using the shared keys shared beforehand. When the source node receives the report with the digital signature from each of the at least one intermediate node and the at least one destination node, the source node can verify that the digital signature of the report came from the intermediate node or the destination node by using the corresponding public keys or the shared keys shared beforehand. If digital signatures are present and match the public keys or shared keys of the intermediate node and the destination node, the source node can know with confidence that the source of the report is in fact the intermediate node and the destination node, respectively. Thus, the source node can authenticate the sources of the reports .

[0088] If the source node detects a report without a digital signature or detects a report for which the digital signature does not match a corresponding public key or shared key, the source node may determine that a security incident has happened and may trigger remediations .

[0089] Instead of transmitting reports from each node independently to the source node, the reports of the at least one destination node and the at least one intermediate node may be concatenated and hashed to generate a chain of reports with the hash value . Then, the source node may not receive a plurality of reports, transmitted independently from each node, but a chain of reports . The source node may verify the integrity of each report in the chain of reports based on the hash value . This concept is similar to blockchain, wherein at the end of the key distribution, the source node initiating the request for key distribution may receive a chain of allreports, from each node having received and forwarded the key, and a corresponding hash value .

[0090] According to an example in a QKD system, a report composed of cryptographic proofs may be a chain, of length N, of reports of correct cryptographic operations generated by KMS instances involved, such as KMS Bl and KMS Cl shown in FIG .

[0091] 3. For example, KMS Cl may sign the report and may transmit the signed report to the QKDN controller of site N-l in the transmission chain, such as the QKDN controller B of QKD node B . The SDN orchestrator 310 may instruct its local KMS, such as KMS Bl, to compute a hash value for the report received from the QKDN controller of site N, such as the QKDN controller C, concatenate it with the report generated from the local KMS instance at site N-l, such as KMS Bl, have the output signed using, for example, the private key or shared key stored in QKD node B, and have the concatenated and signed report transmitted to the QKDN controller at site N-2, such as the QKDN controller A. If the SDN orchestrator 310 includes a plurality of SDN controllers (as shown in FIG. 4, for example, ) , the SDN controller of each site may instruct its local KMS to perform the steps of computing a hash value, concatenating the hash value with a report, and signing the report . These steps may be repeated until the QKDN controller of the source node receives the chain of reports . At the end of this process, the QKDN controller serving the user that initiated the key distribution, such as the QKDN controller A serving KMS U99, may receive a chain of reports summarizing all reports of the KMS instances involved in the key distribution and can verify that the path taken for the key distribution matches the policy requirement . The integrity of the reports in the chain may be proved by the hash value, whereas the origin of the reports may be proved by the digital signatures that can be verified with a repository of public keys .According to another embodiment, the source node may further determine that a security incident has occurred if the source node does not receive the report . Thus, the absence of a report that should have been sent by a node involved in the key distribution based on the policy requirement may be considered a security incident that shall be noticed by the source node in order to trigger remediations .

[0092] Thus, checking the policy requirements for consistencies and feasibility of key distribution and generating reports may provide the possibility to implement specific use cases and to provide corresponding error messages sent back to the user initiating the request . The level of security in key distribution can be significantly improved and adequate security control can be effectively ensured.

[0093] As described in detail above, a report may be transmitted from the at least one intermediate node and the at least one destination node to the source node . It is also possible that a report is transmitted, by the source node and the at least one intermediate node, to the at least one destination node . For example, the source node and each of the at least one intermediate node generates a report to be transmitted to the at least one destination node, wherein each report includes at least one of an alert on a deviation from the policy requirement, an alert on a security incident, and a cryptographic proof . For further details regarding reports including alerts, it is referred to the above-described embodiments for conciseness reasons, wherein the source node and the at least one intermediate node may generate the reports on the alerts . If a deviation or a security incident is indicated in the reports from the source node and / or the intermediate node, the at least one destination node may discard the key received upon the key distribution, because the at least one destination node must assume that the key has been manipulated.For further details regarding the cryptographic proof, it is referred to the embodiments described above . For example, the cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using private keys, and the destination node uses corresponding public keys to verify the authenticity of each report . Alternatively, the cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using shared keys, and the at least one destination node uses the shared keys to verify the authenticity of each report, the shared keys being keys shared beforehand between the source node, the at least one intermediate node, and the at least one destination node . Thus, the at least one destination node is able to verify or prove the origin of the report and therefore also of the key. If the origin of the key does not match the route calculated based on the policy requirement, the at least one destination node may discard the distributed key, because the at least one destination node may assume that the key has been manipulated. Also, the at least one destination node may determine that a security incident has occurred if the at least one destination node does not receive the report .

[0094] If there are a plurality of destination nodes, it is possible that some destination nodes may discard the distributed key, while other destination nodes may accept the distributed key. In such a case, the orchestrator of the network may decide whether or not all destination nodes should discard the distributed key, even if initially accepted, to ensure improved security in the whole network.

[0095] Similar to the above, the reports of the source node and the at least one intermediate node may be concatenated and hashed to generate a chain of reports with a hash value . The at least one destination node may verify the integrity of each report in the chain of reports based on the hash value .FIG. 4 shows a schematic diagram of an example of a space quantum communication infrastructure (QCI ) 400 for performing an end-to-end key distribution where at least one node is a satellite . The satellite 420 may act as a relay node over long distance . As shown in FIG. 4, a user Al may be connected to site A, a user Bl may be connected to site B, a user C3 may be connected to site C, and a user C4 may be also connected to site C . KMS-userAl may require a shared secret, such as a key, to be exchanged, i . e . distributed, between sites A, C, and B, such that the users Bl, C3, and C4 can receive the key. The KMS-userAl, KMS-userBl, KMS-userC3, and the KMS-userC4 are examples of secure application entities (SAEs) , wherein the SAEs may request a service and may be collocated in trusted nodes as per recommendations on ETSI papers for key distribution (see, for example, ETSI GS QKD 014 VI . 1.1, page 9) . For example, the SAEs request respective KMS to deliver keys, wherein the KMS may deliver the keys according to the request .

[0096] The infrastructure 400 in FIG. 4 shows an SDN orchestrator 410 with SDN controllers 411, 412, 413, and 414 and a QKD node 440, a QKD node 450, a QKD node 460, and a QKD node 470. QKD node 440 serves a site A, QKD node 450 serves a site D, QKD node 460 serves a site C, and QKD node 470 serves a site B . The QKDN nodes may be ground terminal (GT) nodes . The SDN controllers 411, 412, 413, and 414, may perform controls for their local KMS instances . The satellite' s payload operation center (DOG) 430 may be a specific instance of a QKD controller for the KMS of the satellite 420.

[0097] The satellite 420, in particular the QKD module Bob of the satellite 420, may be connected to the QKD modules Alice, Dean, Bernard, and Charly of the QKD nodes 440, 450, 470, and 460, respectively, over authenticated channels 401 and QKD channels 402. The QKD modules Alice, Dean, Bernard, and Charly of the QKD nodes 440, 450, 470, and 460 and the QKDmodule Bob of the satellite 420 may be used to generate quantum keys as explained above . The QKD nodes 440, 450, 460, and 470 can further communicate with each other over a network 480, wherein part of the communication can be over a classical, i . e . non-quantum, network, such as a public or private communication network. For example, wrapped keys can be transmitted over a public network and / or a virtual private network (VPN) to the destination nodes .

[0098] The QKD nodes may include at least one software and / or hardware instance to serve users . The instances may be served by the ground terminal KMS, see KMS-GT A of site A, KMS-GT D of site D, KMS-GT C of site C, and KMS-GT B of site B . For instance, two instances KMS-A1 and KMS-A2 are served by KMS-GT A, two instances KMS-D1 and KMS-D2 are served by KMS-GT D, two instances KMS-C3 and KMS-C4 are served by KMS-GT C, and one instance KMS-B1 is served by KMS-GT B . The instance KMS-A1 may serve user KMS-userAl, the instance KMS-C3 may serve user KMS-userC3, the instance KMS-C4 may serve user KMS-userC4, and the instance KMS-B1 may serve user KMS-userBl . Thus, the KMS on user side, e . g. KMS-userAl, KMS-userBl, KMS-userC3, and KMS-userC4, can be served by dedicated KMS instances and can access only assets related to their services . A user, such as a customer, key consumer, or third-party QCI operator, may place the key distribution request via the KMS-userAl . KMS-A1, KMS-C3, KMS-C4, and KMS-B1 may be a group of KMS specified to relay a key and may be in the first peripheral layer of the QCI infrastructure . For example, there are two instances of KMS that contribute to a service : 1 ) the core functions may be endorsed by a SpaceQCI-KMS, such as the KMS of satellite 420 and KMS-GT A, KMS-GT B and KMS-GT C in FIG. 4, and may be specific to QKD over space-to-ground applications, and 2 ) a first peripheral layer may be made of off-the-shelf KMS (also called service-KMS, usually compliant with NIST-SP800-57 ) , wherein the service-KMS may realize services for a user and may request quantum key material from the core functions . Depending on thearchitecture, there can be several service-KMS (such as KMS-Al, KMS-C3, KMS-C4, and KMS-B1 in FIG. 4 ) served by a single SpaceQCI-KMS (such as the KMS of satellite node 420 in FIG.

[0099] 4 ) .

[0100] KMS-D1 and KMS-D2 in FIG. 4 might not belong to a user and might therefore not be operated by a user but by an operator of the space QCI 400. For example, the KMS-D1 and KMS-D2 are service-KMS as explained above and may be under the responsibility of the QCI operator . KMS-userDl and KMS-userD2 (not shown in FIG. 4 ) may be SAEs as explained above and may be under the responsibility of a user . This may emphasize the need for isolated and dedicated software and / or hardware instances for serving different users and operators .

[0101] The SDN controllers 411, 412, 413, and 414 may instruct their respective KMS instances to perform specific services, such as calculating hash values if required (see description above) , wherein the calculation of the hash values may be delegated to a commercial-off-the-shelf (COTS) function not represented in FIG. 2 and endorsed by a service-KMS . Other examples for specific services instructed by the SDN controllers 411, 412, 413, and 414 are illustrated in FIG. 2 by way of example, see the box "Key manager (KM) " in FIG. 2. For example, the SDN controller 411 instructs the Key Management System Ground Terminal (KMS-GT) A of QKD node 440, the SDN controller 412 instructs the KMS-GT D of QKD node 450, the SDN controller 413 instructs the KMS-GT C of QKD node 460, and the SDN controller 414 instructs the KMS-GT B of QKD node 470. The KMS-GT instances for the sites A, B, C, and D may refer to a group of KMS specific to the space segment and may perform specific operations related to the space segments, such as pair-wise key sharing, key synchronization, etc . .

[0102] In FIG. 4, a request for key distribution may be initiated by KMS-userAl at site A. For example, the user KMS-userAl, i . e .the initiator of the key distribution, requests a service of a key transport, i . e . key distribution, from KMS-userAl to KMS-userBl, KMS-userC3, and KMS-userC4 . The requests may be placed through a KMS-userAl interface with the serving node of the KMS-userAl . There may be two options . The first option may be that the request is sent to the KMS-A1 . This means that the key is transferred by a user, such as a customer, key consumer, or third party QCI operator, through an interface to KMS-A1, wherein KMS-A1 wraps the key with its quantum key and transfer the wrapped key to a peering KMS . The second option may be that the request may be placed, by the user, on an interface between the KMS-userAl and the QKDN controller (not shown in FIG. 4 ) of QKD node 440 serving the KMS-userAl, wherein the request may be sent to the QKDN controller and the KMS-userAl receives a quantum key from KMS -Al . KMS-userAl may perform wrapping of the key and transfer the wrapped key to the peering KMS . Whether to use the first or second option may depend on security concepts requested by the user .

[0103] Policy requirements for the key distribution may be defined. For example, the policy requirement of KMS-userAl may include sharing the key only with KMS-B1 , KMS-userBl, KMS-C3, KMS-userC3, KMS-C4, and KMS-userC4 . If another policy requirement is defined, such as a policy requirement excluding KMS-C3, KMS-C3 may not be allowed to participate in the key distribution and therefore KMS-userC3 may not have access to the distributed key.

[0104] FIG. 5 shows a schematic diagram of an example of a simplified space QCI performing an end-to-end key distribution. Specifically, FIG. 5 shows a route computed in the QCI 400 of FIG. 4 for key distribution. Here, the QKD node A with the reference sign 510 in FIG. 5 may correspond to QKD node 440 in FIG. 5, the satellite node 520 in FIG. 5 may correspond to the satellite node 420 in FIG. 4, the QKD node B with reference sign 530 in FIG. 5 may correspond toQKD node 470 in FIG. 4, and the QKD node C with reference sign 540 in FIG. 5 may correspond to QKD node 460 in FIG. 4 . FIG. 5 illustrates a policy requirement to transmit a key from the source node, here the QKD node 510, via the intermediate node, here the satellite node 520, to the destination nodes, here the QKD nodes 530 and 540 (similar to FIG. 4 ) . As destination node, not only a specific QKD node may be selected, but it is also possible to select a specific software and / or hardware instance within the QKD node . For example, the destination node may be KMS-C3, wherein KMS-C4 may be excluded. Thus, the key may only be transmitted to KMS-C3 and not to KMS-C4 .

[0105] It is noted that from the standpoint of a destination N, here KMS-B1, KMS-C3, and KMS-C4, the satellite node may be the node N-l and the QKD node 510 may be the node N-2, wherein the QKD node 510 may be the initiator of a key distribution request .

[0106] According to an embodiment, a name resolution service to translate the identifications of the nodes involved in the key distribution, such as the intermediate nodes and the destination nodes, into unique identifications, e . g. UUID, of the nodes and their KME instances may be provided as prerequisite . This means that each node and / or each KME instance may have a unique identification. Thus, a QCI operator can translate, i . e . derive, that the key distribution initiated by the request should involve KMS-B1, KMS-C3, and KMS-C4, for example . Another pre-requisite may be to provide a physical connectivity to the source node 510, such that a user, e . g. a customer, key consumer, or third party QCI operator, can place the request at the source node 510.

[0107] When a request is placed by the user at the source node 510, the quantum keys available between the satellite 520 and each of the ground terminals, here KMS-GT A, KMS-GT B, and KMS-GT C, may be involved in computing processes performed for thekey distribution. More precisely, quantum keys may be stored locally and may be shared between KMS-GT A of the QKD node 510 and the satellite 520, between KMS-GT B of the QKD node 530 and the satellite 520, and between KMS-GT C of the QKD node 540 and the satellite 520 in order to perform secure key distribution. To decrease delays in the key distribution, the quantum keys between the satellite 520 and the ground terminals may be generated and shared before a request at the source node 510 is accepted. For example, if the user places a request before the quantum keys between the satellite 520 and the three ground terminal KMS, such as KMS-GT A, KMS-GT B, and KMS-GT C, could have been generated, there may be a delay until the key distribution in response to the request can be performed. To mitigate the delay, the request may be analyzed by a QKDN management network, such as the SDN orchestrator 410 shown in FIG. 4, and may be rej ected or may otherwise not be accepted as long as pre-requisites are not met, such as the generation of quantum keys .

[0108] In order to implement a cryptographic proof and use public and private keys for determining the origins of reports, as described in detail above, a repository of public keys from all KMS instances of the QCI operator running the space QCI may be provided. This repository may be maintained by the QCI operator and may be made available to all users served by the space QCI operator, such as the KMS-userAl, KMS-userBl, KMS-userC3, and KMS-userC4 . Instead of a repository of public keys, shared keys as described above may be used, these shared keys may be shared and stored beforehand by the source node, the at least one intermediate node, and at least one destination node . Thus, the users can verify the origins of reports generated to provide feedback regarding the key distribution based on the policy requirement . This means that the repository of public keys may ensure that asymmetric cryptography can be performed, wherein the private keys are securely stored by each node in the QCI 400 or 500 and the public keys are made available to the users initiating thekey distribution request or to the users receiving the key, for example . The users can use these public keys to verify the authenticity of each signature included in the reports in order, in turn, to verify the integrity and non-repudiation of the reports .

[0109] Once a request for key distribution is placed by a user in the QCI 400 or 500, the request may be analyzed by the management layer of the QCI domain, such as the SDN orchestrator 410 in FIG. 4. The SDN orchestrator 410 may validate the feasibility of the key distribution based on the policy requirement and check the consistency of the request . If it is not feasible to distribute the key based on the policy requirement, the SDN orchestrator 410 may rej ect the request (see also the embodiments described above) .

[0110] Furthermore, the SDN orchestrator 410 may compute a route to transfer the key to be distributed between all nodes mentioned in the request, i . e . all nodes used for the key distribution and defined by the policy requirement . In the example of FIGs . 4 and 5 showing a star topology with the satellite node 420 and 520 in the center, the nodes involved in the routing are the KMS instance of the satellite 420, 520, the KMS-GT A, the KMS-GT B, and the KMS-GT C . These KMS instances are the KMS instances to realize a 1 : 1 pairwise key distribution. Then, KMS-userAl, KMS-userC3, KMS-userC4, and KMS-userBl are involved in the distribution. Thus, the KMS at the sites A, B, and C each have a quantum key generated with the satellite node 420, 520 (here : the center of the star topology) , wherein a mechanism to combine these quantum keys with the key to be distributed may include performing a XOR operation of the respective quantum key and the key to be distributed. These quantum keys may be used to securely distribute the key from the KMS of the source node to each destination KMS involved. The SDN orchestrator 410 may identify the KMS-GTs and the KMS that are involved in the key distribution. Then, the SDN orchestrator 410 may instruct toperform key wrapping between the key to be distributed and the quantum keys, as described above, in order to allow to share the key with N-l destination nodes . In general, it can be said that a group of N sites, the number of pair-of-site-KMS that shall have a quantum key in common is

[0111]

[0112] It is noted that, in order to save one hop, it may be possible to use a quantum key between the source node and a next node as a key to be distributed.

[0113] Moreover, the SDN orchestrator 410 may provide a set of instructions to controller entities of each node involved in the key distribution, such as nodes 420, 440, 460, 470 (or 510, 520, 530, 540 of FIG. 5) , in order to implement a sequence of cryptographic functions for performing the routing. For example, a satellite-specific KMS, such as the KMS of satellite 420, 520, may store the quantum keys shared over long distance between the satellite and each of sites A, B, C, and D in order to realize 1 : 1 pairwise key sharing, for example . The satellite-specific KMS may be instructed by the POC 430, which is a specific instance of a QKD controller for the satellite 420, 520. User KMS, such as KMS-userAl, KMS-userC3, KMS-userC4, and KMS-userBl, may be provided with the result of key combination required to protect the user keys provided at a source node 440. It is noted that the source node 440 may also be called "initiator node", because this node may receive a request pushed by a user for QKD service and relay it to the SDN orchestrator 410 via its SDN controller 411.

[0114] These quantum keys may be selected to combine them with keys to be distributed or with other quantum keys . A quantum key may be defined as a key created out of a quantum random number generator (QRNG) using a physical phenomenon observed through quantum physic to generate the entropy. As anexample, a quantum key may be generated over a quantum channel, such as over a tree-space optical channel, based on a bit sequence obtained from a random number generator using the BB84 protocol or any other suitable QKD scheme . The QKD nodes may or might not use one or many QRNG depending on the applied protocols, and the combination of quantum keys shared between two QKD nodes may be required to relay keys along the QCI network. Thus, the quantum keys may be combined with the keys to be distributed or with other quantum keys, be it in space QCI or terrestrial QCI, in order to share keys between all the user KMS involved.

[0115] It is noted that key combination mechanisms between the KMS of the satellite 420, 520, and the orchestration layer are not described in more detail here for conciseness reasons . It is generally referred to ETSI GS QKD 015.

[0116] Each QKDN controller instance on the serving site, such as the QKDN controller of the QKD nodes 470 and 460 at sites B and C of FIG. 4 (in FIG. 5 of nodes 530 and 540) , may receive a confirmation that cryptographic operations have been realized by each KME instance within their sites . This confirmation may be the reports described above, wherein the reports may be digitally signed by each KMS instance including time stamps of operations when quantum keys were made available on a delivery interface to a user and a selection of quantum keys metadata . For example, a key ID, that has been created, may be required. The key ID, such as an UUID, may be unique and may be considered in the lifecycle management of a key, wherein specific quantum keys generated within the QCI may be identified and reserved for services to be delivered. The key ID, such as the UUID of the key used for wrapping and the UUID of the key wrapped and distributed to the user, may be included in the report .

[0117] Each QKDN controller may relay the reports to the element that has triggered the quantum key generation, the generatedquantum key having been used to wrap the key to be distributed on the N-l hop . In the example of FIGs . 4 and 5, each QKDN controller may report to the satellite QKDN controller, here the POC 430. The QKDN controller of the satellite 420 may hash the received reports and concatenate the hash value with the report of its own KMS, on-boarded onto the satellite 420, into a chain of reports sent to the N-2 QKDN controller, here the QKDN controller of QKD node 440 (or 510 in FIG. 5) at site A. In the end, the user initiating the key distribution request may receive the chain of reports and corresponding hash value . The integrity of all reports included in the chain is proved by the hash value and the origin of the reports is proved by the digital signature that can be verified with a repository of public keys .

[0118] It is noted that the processes of FIGs . 4 and 5 can be similarly applied to a terrestrial QKD segment that can be operated by a satellite QCI operator . In such a case, the user can be far from the ground terminal locations, e . g. further than 80 km away.

[0119] Furthermore, it is noted that the absence of a report received by a KMS in the QCI 400 or 500 involved in the key distribution may be considered a security incident that shall be reported.

[0120] FIG. 6 shows a schematic diagram of a system 600 for key distribution according to an embodiment . The system 600 may be a communication system as described above, such as a QKD system. The system 600 may comprise a source node 610, at least one intermediate node 620, and at least one destination node 630. For further details regarding the source node 610, the at least one intermediate node 620, and the at least one destination node 630, we refer, for conciseness reasons, to the description provided above . The source node 610 may be configured to receive a request for distributing a key to the at least one destination node 630, the request including apolicy requirement for distributing the key from the source node 610 via the at least one intermediate node 620 to the at least one destination node 630. The key may be distributed to the at least one destination node 630 based on the policy requirement . A report providing feedback regarding the key distribution based on the policy requirement may be transmitted .

[0121] The source node 610, the at least one intermediate node 620, and the at least one destination node 630 may each include a respective processing unit 611, 621, 631 and / or any other control circuitry to carry out and / or control any method described herein with regard to the system. Also, a storage unit or any other storage medium (not shown) may be included in the source node 610, the at least one intermediate node 620, and the at least one destination node 630 in order to store quantum keys and other keys used for asymmetric cryptography, for example . There is also generally considered a computer program product comprising instructions adapted for causing the processing units and / or any other control circuitry of the nodes to carry out and / or control any method described herein with regard to the system, in particular when executed on the processing unit and / or control circuitry. Also, there is considered a carrier medium arrangement carrying and / or storing a computer program product as described herein.

[0122] It is noted that the invention also relates to the processing performed on a source node (as described above) , to the processing performed on an intermediate node (as described above) , to the processing performed on a destination node (as described above) , and to these nodes when considered individually .

[0123] Above, embodiments for security controls have been described, to ensure that user requests for key distribution are efficiently and securely fulfilled, while providing acryptographic proof of application, i . e . fulfilment, of a policy requirement . Thus, methods and systems for improving the level of security in key distribution and ensuring adequate security control are provided, wherein security incidents can be quickly and efficiently detected and remediated .

[0124] It will be apparent to those skilled in the art that various modifications and variations can be made in the entities and methods of this invention as well as in the construction of this invention without departing from the scope or spirit of the invention.

[0125] The invention has been described in relation to particular embodiments and examples which are intended in all aspects to be illustrative rather than restrictive . Those skilled in the art will appreciate that many different combinations of hardware, software and / or firmware will be suitable for practicing the present invention.

[0126] Moreover, other implementations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and the examples be considered as exemplary only. To this end, it is to be understood that inventive aspects lie in less than all features of a single foregoing disclosed implementation or configuration. Thus, the true scope and spirit of the invention is indicated by the following claims .

Claims

1. CLAIMS1. A method for key distribution in a communication system comprising a source node, at least one intermediate node, and at least one destination node, the method comprising the steps of :receiving a request for distributing a key to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node;distributing the key from the source node to the at least one destination node based on the policy requirement; andtransmitting a report, the report providing feedback regarding the key distribution based on the policy requirement .

2. The method according to claim 1, further comprising:checking the policy requirement before distributing the key to validate the feasibility of the key distribution based on the policy requirement; andrej ecting the request if it is not feasible to distribute the key based on the policy requirement .

3. The method according to claim 1 or 2, whereinfor distributing the key to the at least one destination node, a route to distribute the key is computed based on the policy requirement, the route including the source node, the at least one intermediate node, and the at least one destination node, wherein the at least oneintermediate node receives and forwards the key intended for the at least one destination node .

4. The method according to any one of claims 1 to 3, whereinthe policy requirement includes at least one of a definition of the at least one destination node for receiving the key, a definition of an exclusion zone through which the key is prohibited to transit, and a definition of a classification of the key to be distributed .

5. The method according to any one of claims 1 to 4 , wherein the report is transmitted, by the at least one intermediate node and the at least one destination node, to the source node .

6. The method according to claim 5, whereineach of the at least one intermediate node and each of the at least one destination node generates a report to be transmitted to the source node, andeach generated report includes at least one of an alert on a deviation from the policy requirement when the key was distributed, an alert on a security incident, and a cryptographic proof .

7. The method according to claim 6, whereinthe cryptographic proof is a digital signature generated respectively by the at least one intermediate node and the at least one destination node using private keys, and the source node uses corresponding public keys to verify the authenticity of each report;or the cryptographic proof is a digital signature generated respectively by the at least one intermediate node and the at least one destination node using shared keys, and the source node uses the shared keys to verify the authenticity of each report .

8. The method according to claim 6 or 7, the cryptographic proof being a hash value, whereinthe reports of the at least one destination node and the at least one intermediate node are concatenated and hashed to generate a chain of reports with the hash value, andthe source node verifies the integrity of each report in the chain of reports based on the hash value .

9. The method according to any one of claims 5 to 8 , wherein the source node determines that a security incident has occurred if the source node does not receive the report .

10. The method according to any one of claims 1 to 4 , wherein the report is transmitted, by the source node and the at least one intermediate node, to the at least one destination node .

11. The method according to claim 10, whereinthe source node and each of the at least one intermediate node generates a report to be transmitted to the at least one destination node, andeach generated report includes at least one of an alert on a deviation from the policy requirement when the key was distributed, an alert on a security incident, and a cryptographic proof .

12. The method according to claim 11, whereinthe cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using private keys, and the at least one destination node uses corresponding public keys to verify the authenticity of each report;or the cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using shared keys, and the at least one destination node uses the shared keys to verify the authenticity of each report .

13. The method according to claim 11 or 12, the cryptographic proof being a hash value, whereinthe reports of the source node and the at least one intermediate node are concatenated and hashed to generate a chain of reports with the hash value, andthe at least one destination node verifies the integrity of each report in the chain of reports based on the hash value .

14. The method according to any one of claims 10 to 13, wherein the at least one destination node determines that a security incident has occurred if the at least one destination node does not receive the report .

15. The method according to any one of claims 1 to 14 , whereinthe key is distributed over a quantum key distribution system, andthe source node, the at least one intermediate node, and the at least one destination node are quantum key distribution, QKD, nodes .

16. The method according to claim 15, whereinthe key to be distributed is wrapped using a quantum key, the wrapped key being distributed from the source node via the at least one intermediate node to the at least one destination node,and the at least one destination node unwraps the wrapped key using the quantum key in order to obtain the key to be distributed.

17. A system for key distribution comprising a source node, at least one intermediate node, and at least one destination node, wherein:the source node is configured toreceive a request for distributing a key to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node; andwherein the key is distributed to the at least one destination node based on the policy requirement; anda report is transmitted, the report providing feedback regarding the key distribution based on the policy requirement .

18. The system according to claim 17, whereinthe policy requirement is checked before the source node distributes the key to validate the feasibility of the key distribution based on the policy requirement; andthe request is rej ected if it is not feasible to distribute the key based on the policy requirement .

19. The system according to claim 17 or 18, whereinfor distributing the key to the at least one destination node, a route to distribute the key is computed based on the policy requirement, the route including the source node, the at least one intermediate node, and the at least one destination node, wherein the at least one intermediate node is configured to receive and forward the key intended for the at least one destination node .

20. The system according to any one of claims 17 to 19, whereinthe policy requirement includes at least one of a definition of the at least one destination node for receiving the key, a definition of an exclusion zone through which the key is prohibited to transit, and a definition of a classification of the key to be distributed .

21. The system according to any one of claims 17 to 20, whereinthe at least one intermediate node and the at least one destination node are each configured to transmit the report to the source node .

22. The system according to claim 21, whereineach of the at least one intermediate node and of the at least one destination node is configured to generate a report to be transmitted to the source node, andeach generated report includes at least one of an alert on a deviation from the policy requirement when the key was distributed, an alert on a security incident, and a cryptographic proof .

23. The system according to claim 22, whereinthe cryptographic proof is a digital signature generated respectively by the at least one intermediate node and the at least one destination node using private keys, and the source node is configured to use corresponding public keys to verify the authenticity of each report;or the cryptographic proof is a digital signature generated respectively by the at least one intermediate node and the at least one destination node using shared keys, and the source node is configured to use the shared keys to verify the authenticity of each report .

24. The system according to claim 22 or 23, the cryptographic proof being a hash value, whereinthe reports of the at least one destination node and the at least one intermediate node are concatenated and hashed to generate a chain of reports with the hash value, andthe source node is configured to verify the integrity of each report in the chain of reports based on the hash value .

25. The system according to any one of claims 21 to 24 , wherein the source node is configured to determine thata security incident has occurred if the source node does not receive the report .

26. The system according to any one of claims 17 to 20, wherein the report is transmitted, by the source node and the at least one intermediate node, to the at least one destination node .

27. The system according to claim 26, whereinthe source node and each of the at least one intermediate node are configured to generate a report to be transmitted to the at least one destination node, andeach generated report includes at least one of an alert on a deviation from the policy requirement when the key was distributed, an alert on a security incident, and a cryptographic proof .

28. The system according to claim 27, whereinthe cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using private keys, and the destination node is configured to use corresponding public keys to verify the authenticity of each report;or the cryptographic proof is a digital signature generated respectively by the source node and the at least one intermediate node using shared keys, and the at least one destination node is configured to use the shared keys to verify the authenticity of each report .

29. The system according to claim 27 or 28, the cryptographic proof being a hash value, whereinthe reports of the source node and the at least one intermediate node are concatenated and hashed to generate a chain of reports with the hash value, andthe at least one destination node is configured to verify the integrity of each report in the chain of reports based on the hash value .

30. The system according to any one of claims 26 to 29, wherein the at least one destination node is configured to determine that a security incident has occurred if the at least one destination node does not receive the report .

31. The system according to any one of claims 17 to 30, whereinthe system is a quantum key distribution system, andthe source node, the at least one intermediate node, and the at least one destination node are quantum key distribution, QKD, nodes .

32. The system according to claim 31, whereinthe key is wrapped using a quantum key, the wrapped key being distributed via the at least one intermediate node to the at least one destination node; andthe at least one destination node is configured to unwrap the wrapped key using the quantum key in order to obtain the key to be distributed.

33. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of :receiving a request for distributing a key, in a communication system comprising a source node, at least one intermediate node, and at least one destination node, to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node;distributing the key from the source node to the at least one destination node based on the policy requirement; andtransmitting a report, the report providing feedback regarding the key distribution based on the policy requirement .

34. The computer program according to claim 33, comprising instructions which, when the program is executed by the computer, cause the computer to carry out the method according to any one of claims 1 to 16.

35. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of :receiving a request for distributing a key, in a communication system comprising a source node, at least one intermediate node, and at least one destination node, to the at least one destination node, the request including a policy requirement for distributing the key from the source node via the at least one intermediate node to the at least one destination node;distributing the key from the source node to the at least one destination node based on the policy requirement; andtransmitting a report, the report providing feedback regarding the key distribution based on the policy requirement .

36. The computer-readable medium according to claim 25, comprising instructions which, when executed by the computer, cause the computer to carry out the method according to any one of claims 2 to 16.

37. A node for key distribution in a communication system, the node being configured to :receive a request for distributing a key to at least one destination node, the request including a policy requirement for distributing the key from the node via at least one intermediate node to the at least one destination node;wherein the key is distributed to the at least one destination node based on the policy requirement; anda report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

38. A method performed by a node in a communication system for key distribution, the method comprising:receiving a request for distributing a key to at least one destination node, the request including a policy requirement for distributing the key from the node via at least one intermediate node to the at least one destination node;wherein the key is distributed to the at least one destination node based on the policy requirement; anda report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

39. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claim 38.

40. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 38.

41. A node for key distribution in a communication system, the node being configured to :receive a key, the key being distributed based on a policy requirement for distributing the key from a source node via the node to at least one destination node ;wherein the key is distributed to the at least one destination node based on the policy requirement; anda report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

42. A method performed by a node in a communication system for key distribution, the method comprising:receiving a key, the key being distributed based on a policy requirement for distributing the key from a source node via the node to at least one destination node ;wherein the key is distributed to the at least one destination node based on the policy requirement; anda report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

43. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claim 42.

44. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 42.

45. A node for key distribution in a communication system, the node being configured to :receive a key, the key being distributed based on a policy requirement for distributing the key from a source node via at least one intermediate node to the node ;wherein a report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

46. A method performed by a node in a communication system for key distribution, the method comprising:receiving a key, the key being distributed based on a policy requirement for distributing the key from a source node via at least one intermediate node to the node ;wherein a report is generated in the communication system, the report providing feedback regarding the key distribution based on the policy requirement .

47. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claim 46.

48. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 47.

Images