**2.1 Principle of point-to-point QKD**

The basic principle of point-to-point QKD is introduced based on the first invented QKD protocol, i.e., BB84 protocol proposed by Bennett and Brassard in 1984 [19], as illustrated in **Figure 1**. Nowadays, BB84 protocol is widely used in practical QKD systems [20, 21]. The BB84 protocol based QKD process is summarized in the following three stages.

**13**

*Quantum Key Distribution (QKD) over Software-Defined Optical Networks*

1.Qubit exchange: QKD transmitter (called Alice) generates qubits and sends them to the QKD receiver (called Bob) via a quantum channel (QCh). The qubits are generated by encoding a string of classical bits into single-polarization photons with different states. For instance, the horizontal, vertical, and diagonal ±45° polarization states randomly selected from two conjugate bases (i.e., rectilinear+ and diagonal×) are encoded with 0+, 1+, 1×, and 0×, respectively. In order to achieve accurate qubit synchronization, a clock channel is also required here. Bob receives the incoming qubits and measures each single-polarization photon with one of the two conjugate bases (i.e., rectilinear+ and diagonal×), and it will record the measurement results and

2.Key sifting: Alice and Bob exchange their selected bases via a pubic channel (PCh), and then discard the qubits sent and measured with different conjugate bases. The remaining qubits will be decoded into a string of classical bits as

3.Key distillation: For error estimation and correction, a random substring of classical bits in sifted keys is exchanged and compared between Alice and Bob via the PCh. Finally, privacy amplification and authentication are imple-

Additionally, to improve the secret key rate in QKD systems in practice, decoystate can be integrated with BB84 protocol to basically reach the single-photon sources performance and estimate the number of single-polarization photons

The secret key rate and distance of QKD are limited due to the attenuation of weak quantum signals in QChs. This limitation can be overcome by using quantum repeaters, but they are beyond any practical technologies today [22]. A compromise and a practical solution to this challenge are using trusted repeaters, and this technique has been applied in the deployment of most QKD networks up to date [23–25]. In a QKD network based on trusted repeaters, the secret keys generated on the first QKD link can be relayed to the destination node by encrypting them with the secret keys generated in the intermediate nodes. One-time pad algorithm is applied for encryption to ensure the information-theoretic security of secret keys verified by Shannon [26], while the size of secret keys generated and encrypted here should be the same. Hence, secret keys are known by all intermediate nodes,

making the secret key secure only as long as all the repeaters are trusted.

An example of QKD distance extension based on a trusted repeater between the source and destination nodes is illustrated in **Figure 2**. The QKD transmitter in the source node establishes a QKD link with the forthcoming QKD receiver in the intermediate node, whereas the QKD receiver in the destination node establishes a QKD link with the previous QKD transmitter in the intermediate node. Both QKD links produce, independently, secret keys *Sk*1 and *Sk*2 with the same key size. Then, the secret key *Sk*1 is encrypted with the secret key *Sk*2 and relayed to the destination node. Specifically, secret key *Sk*1 can be used later to secure communications between the source and destination nodes. This relay process can continue with any amount of intermediate nodes, but each intermediate node with the trusted

mented to decide the remaining secure bits as secret keys.

*DOI: http://dx.doi.org/10.5772/intechopen.80450*

the selected bases.

detected by Bob more precisely [8].

**2.2 Trusted repeaters for distance extension**

repeater will know the secret key information.

sifted keys.

### **Figure 1.**

*Principle of point-to-point QKD based on BB84 protocol.*

*Quantum Key Distribution (QKD) over Software-Defined Optical Networks DOI: http://dx.doi.org/10.5772/intechopen.80450*

*Quantum Cryptography in Advanced Networks*

the security of SDONs.

**2.1 Principle of point-to-point QKD**

rized in the following three stages.

*Principle of point-to-point QKD based on BB84 protocol.*

**2. Basic principles and enabling technologies of QKD**

The basic principle of point-to-point QKD is introduced based on the first invented QKD protocol, i.e., BB84 protocol proposed by Bennett and Brassard in 1984 [19], as illustrated in **Figure 1**. Nowadays, BB84 protocol is widely used in practical QKD systems [20, 21]. The BB84 protocol based QKD process is summa-

Data encryption is an effective way to enhance the security of SDONs. However, classical key distribution methods are based on the mathematical and computational complexities, which will suffer from increased computational power and developed quantum computing in the near future [7]. Quantum key distribution (QKD) is a promising technique to secure key exchange and protect communications from security attacks in SDONs [8]. It can achieve information-theoretic security based on the fundamentals of quantum physics, such as the Heisenberg uncertainty principle and quantum no-cloning theorem [9, 10]. Moreover, these fundamentals guarantee that the senders or receivers can detect the presence of any third party who is trying to obtain the secret keys. Optical fibers can be used in QKD systems to achieve good transmission performance of quantum signals. Nevertheless, the dark fibers utilized for QKD systems are inconvenient and expensive, while a potential solution is to use wavelength division multiplexing (WDM) technique for QKD integration in existing optical networks [11]. A lot of experiments and field trials have demonstrated the feasibility and practicability of integrating QKD into optical networks [12–18]. Therefore, based on above works, the objective of this chapter is to find how to deploy and employ QKD to enhance

**12**

**Figure 1.**


Additionally, to improve the secret key rate in QKD systems in practice, decoystate can be integrated with BB84 protocol to basically reach the single-photon sources performance and estimate the number of single-polarization photons detected by Bob more precisely [8].

### **2.2 Trusted repeaters for distance extension**

The secret key rate and distance of QKD are limited due to the attenuation of weak quantum signals in QChs. This limitation can be overcome by using quantum repeaters, but they are beyond any practical technologies today [22]. A compromise and a practical solution to this challenge are using trusted repeaters, and this technique has been applied in the deployment of most QKD networks up to date [23–25]. In a QKD network based on trusted repeaters, the secret keys generated on the first QKD link can be relayed to the destination node by encrypting them with the secret keys generated in the intermediate nodes. One-time pad algorithm is applied for encryption to ensure the information-theoretic security of secret keys verified by Shannon [26], while the size of secret keys generated and encrypted here should be the same. Hence, secret keys are known by all intermediate nodes, making the secret key secure only as long as all the repeaters are trusted.

An example of QKD distance extension based on a trusted repeater between the source and destination nodes is illustrated in **Figure 2**. The QKD transmitter in the source node establishes a QKD link with the forthcoming QKD receiver in the intermediate node, whereas the QKD receiver in the destination node establishes a QKD link with the previous QKD transmitter in the intermediate node. Both QKD links produce, independently, secret keys *Sk*1 and *Sk*2 with the same key size. Then, the secret key *Sk*1 is encrypted with the secret key *Sk*2 and relayed to the destination node. Specifically, secret key *Sk*1 can be used later to secure communications between the source and destination nodes. This relay process can continue with any amount of intermediate nodes, but each intermediate node with the trusted repeater will know the secret key information.

### **Figure 2.**

*An example of QKD distance extension based on a trusted repeater between the source and destination nodes.*

### **Figure 3.**

*An example of QKP for secret key provisioning between Node-A and Node-B.*

### **2.3 Quantum key pool (QKP) for secret key provisioning**

Currently, the secret key rate in most QKD systems can only reach 1–2 Mbit/s over a 50 km fiber link [27]. Therefore, the efficient management of precious secret key resources is important. Recently, quantum key pool (QKP) technique is proposed in QKD networks to timely provision secret keys for satisfying the security demands of communications crossing the networks [6], which is beneficial to enhance secret key management when the QKD develops from point-to-point links to networks. The secret keys generated between the two end nodes can be stored in the key store (KS) which is embedded in each of the two end-nodes and can be managed by a QKP. QKP will know the real-time remaining number of secret keys in the KS, which can decide when to connect the QKD link for secret key provisioning. Hence, efficient QKP construction is beneficial for efficiently employing QKD.

An example of QKP between Node-A and Node-B is illustrated in **Figure 3**. The QKD node is composed of several components based on the existing QKD technologies, e.g., QKD transceiver, trusted repeater, and switch [23]. The generated secret keys between QKD Node-A and QKD Node-B can be stored in KS-A and KS-B, which are embedded in Node-A and Node-B, respectively. Specifically, the generated secret keys are managed by QKPA–B to monitor the real-time remaining number of secret keys and provision secret keys between Node-A and Node-B.

## **3. QKD over SDON Architecture**

An architecture of QKD over SDONs is illustrated in **Figure 4(a)**, which consists of four layers from top to bottom: application (App) layer, control layer, QKD layer,

**15**

**Figure 4.**

*Quantum Key Distribution (QKD) over Software-Defined Optical Networks*

and optical layer. This architecture is different from the previous QKD-integrated optical networks [11] and decouples QKD layer from the optical layer via constructing several QKPs in the QKD layer. Two types of QKPs are constructed to enhance the security of control signaling messages over the CChs, and confidential data services over the DChs, respectively. The QKP between the SDN controller and each node is called QKP-C (i.e., QKP-CCh), whereas the QKP between two nodes is called QKP-D (i.e., QKP-DCh). The SDN controller in the control layer controls and manages the QKD layer and optical layer via the southbound interface protocol (e.g., OpenFlow and NETCONF). Here we use OpenFlow protocol as an example. The SDN controller is capable of realizing flexible and programmable global optical network management, which can be utilized as the effective implementation technique for control layer. Moreover, it has been demonstrated in the recent study

*(a) QKD over SDON architecture; and (b) the configuration signaling procedure.*

on time-shared QKD resources in SDN-controlled optical networks [28].

based on the instructions from SDN controller.

Optical layer and QKD layer can share the fiber bandwidth resources from existing WDM networks, in which at least two wavelengths need to be utilized as QCh and PCh to construct OpenFlow-enabled QKPs (OF-QKPs), and then the remaining wavelength resources can be utilized to transport confidential data services. The constructed OF-QKPs can provision secret keys to guarantee the security of CChs and DChs. In addition, OpenFlow-enabled optical cross connects (OF-OXCs) are placed in the optical layer. The SDN controller is capable of managing the entire network efficiently, whereas the OF-QKPs and OF-OXCs are capable of operating

The App layer generates service requests with different security demands and interacts with control layer via the Restful API, in which Restful API is applied as northbound interface protocol. Based on the different security demands, CChs and DChs may require different number of secret keys. In particular, this QKD over SDON architecture can manage and control the network-wide secret key resources, which is beneficial to adapt diverse security demands and dynamic scenarios. **Figure 4(b)** illustrates the configuration signaling procedure among the four layers in QKD over SDON architecture. This procedure can be described in the following five stages: (1) upon receiving a service request (e.g., the service request from Node 1 to Node 2) from the App, SDN controller first computes/selects path and then implements OpenFlow handshake with related OF-OXCs as well as OF-QKPs on the selected path; (2) after the establishment of first stage, OF-QKP-C1 and OF-QKP-C2 are configured by the SDN controller to provision secret keys for

*DOI: http://dx.doi.org/10.5772/intechopen.80450*

*Quantum Key Distribution (QKD) over Software-Defined Optical Networks DOI: http://dx.doi.org/10.5772/intechopen.80450*

**Figure 4.** *(a) QKD over SDON architecture; and (b) the configuration signaling procedure.*

and optical layer. This architecture is different from the previous QKD-integrated optical networks [11] and decouples QKD layer from the optical layer via constructing several QKPs in the QKD layer. Two types of QKPs are constructed to enhance the security of control signaling messages over the CChs, and confidential data services over the DChs, respectively. The QKP between the SDN controller and each node is called QKP-C (i.e., QKP-CCh), whereas the QKP between two nodes is called QKP-D (i.e., QKP-DCh). The SDN controller in the control layer controls and manages the QKD layer and optical layer via the southbound interface protocol (e.g., OpenFlow and NETCONF). Here we use OpenFlow protocol as an example. The SDN controller is capable of realizing flexible and programmable global optical network management, which can be utilized as the effective implementation technique for control layer. Moreover, it has been demonstrated in the recent study on time-shared QKD resources in SDN-controlled optical networks [28].

Optical layer and QKD layer can share the fiber bandwidth resources from existing WDM networks, in which at least two wavelengths need to be utilized as QCh and PCh to construct OpenFlow-enabled QKPs (OF-QKPs), and then the remaining wavelength resources can be utilized to transport confidential data services. The constructed OF-QKPs can provision secret keys to guarantee the security of CChs and DChs. In addition, OpenFlow-enabled optical cross connects (OF-OXCs) are placed in the optical layer. The SDN controller is capable of managing the entire network efficiently, whereas the OF-QKPs and OF-OXCs are capable of operating based on the instructions from SDN controller.

The App layer generates service requests with different security demands and interacts with control layer via the Restful API, in which Restful API is applied as northbound interface protocol. Based on the different security demands, CChs and DChs may require different number of secret keys. In particular, this QKD over SDON architecture can manage and control the network-wide secret key resources, which is beneficial to adapt diverse security demands and dynamic scenarios.

**Figure 4(b)** illustrates the configuration signaling procedure among the four layers in QKD over SDON architecture. This procedure can be described in the following five stages: (1) upon receiving a service request (e.g., the service request from Node 1 to Node 2) from the App, SDN controller first computes/selects path and then implements OpenFlow handshake with related OF-OXCs as well as OF-QKPs on the selected path; (2) after the establishment of first stage, OF-QKP-C1 and OF-QKP-C2 are configured by the SDN controller to provision secret keys for

*Quantum Cryptography in Advanced Networks*

**Figure 2.**

**Figure 3.**

**2.3 Quantum key pool (QKP) for secret key provisioning**

*An example of QKP for secret key provisioning between Node-A and Node-B.*

of secret keys and provision secret keys between Node-A and Node-B.

An architecture of QKD over SDONs is illustrated in **Figure 4(a)**, which consists of four layers from top to bottom: application (App) layer, control layer, QKD layer,

**3. QKD over SDON Architecture**

Currently, the secret key rate in most QKD systems can only reach 1–2 Mbit/s over a 50 km fiber link [27]. Therefore, the efficient management of precious secret key resources is important. Recently, quantum key pool (QKP) technique is proposed in QKD networks to timely provision secret keys for satisfying the security demands of communications crossing the networks [6], which is beneficial to enhance secret key management when the QKD develops from point-to-point links to networks. The secret keys generated between the two end nodes can be stored in the key store (KS) which is embedded in each of the two end-nodes and can be managed by a QKP. QKP will know the real-time remaining number of secret keys in the KS, which can decide when to connect the QKD link for secret key provisioning. Hence, efficient QKP construction is beneficial for efficiently employing QKD. An example of QKP between Node-A and Node-B is illustrated in **Figure 3**. The QKD node is composed of several components based on the existing QKD technologies, e.g., QKD transceiver, trusted repeater, and switch [23]. The generated secret keys between QKD Node-A and QKD Node-B can be stored in KS-A and KS-B, which are embedded in Node-A and Node-B, respectively. Specifically, the generated secret keys are managed by QKPA–B to monitor the real-time remaining number

*An example of QKD distance extension based on a trusted repeater between the source and destination nodes.*

**14**

control/configuration messages over the CChs; (3) OF-QKP-D1–2 is configured by the SDN controller to provision secret keys for the service request from OF-OXC1 to OF-OXC2 over the DCh; (4) the SDN controller configures OF-OXC1 and OF-OXC2 to encrypt data and transport the service; and (5) at last, SDN controller replies to the App.
