Interactive simulation of quantum key distribution protocols and application in Wi-Fi networks

Quantum key distribution is a cryptographic protocol that involves quantum mechanics to allow two parties to produce a shared random secret key. Since in quantum mechanics, the measurement process of a quantum system generally perturbs the system, this property can be used to detect eavesdropping between two communicating users. The first QKD scheme, the well-known BB84 protocol, uses photon polarization states to transmit information. Unlike that scheme, the E91 protocol uses entangled pairs of qubits. In particular, pairs of particles are emitted towards the two legitimate users, Alice and Bob, such that the entangled qubits are generated through one of the four the Bell states: \(|\Psi ^{-}\rangle\) (see Eq. (1)). Thus, one qubit from each entangled pair is assigned to each of the two communicating users, Alice and Bob.In the E91 protocol, three measurement bases are considered for each participant, defined by: \(\{ \vec{a}_{1} ,\vec{a}_{2} ,\vec{a}_{3} \}\) for Alice, and \(\{ \vec{b}_{1} ,\vec{b}_{2} ,\vec{b}_{3} \}\) for Bob. For simplicity, both vectors, \(\vec{a}_j\) and \(\vec{b}_j\) (\(j=1,2,3\)), lie in the \(x-z\) plane, perpendicular to the trajectory of the entangled qubits. The Bloch vector notation of each basis is shown in Fig. 1.

Note that the basis \(\vec{a}_1\) represents the Hadamard basis, while the bases \(\vec{a}_3\) and \(\vec{b}_2\) represent the computational basis. It is also important to emphasize that “observable” refers to the measurement with respect to that basis.

Each participant, Alice and Bob, after receiving their assigned qubits, proceeds to measure them by randomly selecting, for each qubit, one of the three available measurement bases. The results are stored privately for each entity. The bases on which the measurements were taken are then shared, which poses no risk since the qubits have already been sent and measured.

In those cases where the measurement bases chosen by Alice and Bob have been equivalent: \((\vec{a}_2/\vec{b}_1 \text { or } \vec{a}_3/\vec{b}_2)\), it will be possible to ensure that, if there has been no eavesdropping, Alice will have obtained the bit-flipped version of Bob’s result and vice versa, thanks to the use of the entanglement based on the antisymmetric Bell state \(|\Psi ^{-}\rangle\). Figure 2 shows the complete bipartite graph representing all possible combinations of Alice and Bob’s measurements. In accordance with this, it can be estimated that, taking the bases at random, approximately \(\frac{2}{9}\) of the qubits will be measured correctly.

For qubits measured with one of the two correct base combinations, a secret key is obtained which is known only to the legitimate participants in the communication. Furthermore, in the E91 protocol it is possible to verify the robustness of the quantum channel and demonstrate the security of that key. For this purpose, the computation of the C value of the so-called CHSH correlation must be used. CHSH stands for Clauser, Horne, Shimony and Holt, who in [17] proved certain consequences of entanglement related to quantum correlations defined by the expectation values of the products of the outcomes. Specifically, in the E91 protocol it is computed using some of the measurements that were not used for the generation of the shared secret key.

With entanglement based on the antisymmetric Bell state, as in the E91 protocol, it has been proven [18] that some incorrect combinations of bases of Alice and Bob (see Fig. 3) can be used to obtain a CHSH equal to \(-2 \sqrt{2}\) if there is no interception in the channel. For instance, considering the measurement bases \(\vec{a}_1/\vec{b}_1 \text {, } \vec{a}_1/\vec{b}_3 \text {, } \vec{a}_3/\vec{b}_1 \text { and } \vec{a}_3/\vec{b}_3\), we have that:

Therefore, if after running the E91 protocol, the value \(C = -2\sqrt{2}\) is obtained for each of the four possible combinations of useful bases of Alice and Bob shown in Fig. 3, then it can be assured that there has been no interception in the quantum channel. Small deviations from this value could be caused by noise in the quantum channel. However, large deviations could mean that communication is compromised. In that case, as in similar protocols, the current operation should be aborted and resumed from the beginning until a good correlation value is achieved. Once the security of the key has been verified, it can be used with any secure secret key encryption. For example, taking advantage of the fact that it is a random key, a one-time pad can be used in which the sender and receiver encrypt and decrypt binary messages using an XOR operation.

This is a protocol where, unlike others, almost all transmitted qubits are used. This is so because most of the values resulting from the measurements on the incorrectly measured qubits that are not valid as part of the key, are nevertheless used to calculate a variable that indicates the security of the communication. In previous protocols, such as BB84, those qubits were completely discarded as useless. Thus, the correlation calculation in the E91 protocol allows the detection of Man-in-the-Middle attacks or the discovery of a corrupted source of interleaved pairs.

Six years after the E91 protocol was first proposed, an implementation of polarization entangled photon distribution using free-space optics [19] was achieved. This was the first step towards a physical implementation of the protocol. Thus, three years after this milestone, the generation of secret keys of up to 800 bits per second was achieved, with a separation between Alice and Bob of 360 ms [20]. Recently, it has been possible to generate secure keys over distance ranges between 530 and 1000 kms at a rate of 3.5 bits, using a low-Earth-orbit satellite [21].

The QuantumSolver library for quantum development [11], recently created and released by the authors of this paper, offers a simple solution to the difficulty of first contact with this type of technology. It manages to encapsulate quantum software in an intuitive way, facilitating possible contributions to this open source project [12]. It includes two different interfaces: command line and web. Each of them is linked to a different audience profile: the first one for people more experienced in software development and computer programming, and the second one for the general public. The results produced by this tool are of great relevance since it allows the execution of the included algorithms, on real quantum hardware offered by IBM, as well as on simulators. The library was initialized with the implementation of the QKD protocol BB84 [4].

The development carried out in this work was integrated into the QuantumSolver library. To represent the participants, an intuitive hierarchy of classes was developed. On the one hand, the abstract class Participant collects common methods and data, such as the attributes of values, axes, keys, etc. On the other hand, its derived classes, Sender and Receiver, contain the specific functions of each entity.

To simulate the eavesdropping case, an Eavesdropper entity was implemented, which randomly chooses the measurement to perform (\(W \otimes W \text { or } Z \otimes Z\)) on all the qubits it intercepts. These measurements are made before the intervention of Alice and Bob, so their results will be modified in such a way that the change in the calculation of the CHSH correlation value can be detected. Thus, the more qubits the eavesdropper intercepts, the more knowledge it will have about the generated key, but at the same time it will also produce a greater deviation from the expected value of the calculated CHSH correlation. Therefore, in the implementation it has been decided to check that the computed CHSH correlation does not deviate more than \(10\%\) from the expected value (see Eq. (3)).Once the eavesdropping control has been successfully passed, the Sender and Receiver entities proceed to consider the generated key as secure to be used. Thus, in the implementation, the Sender entity encrypts with a one-time pad the original message with that secret key, the transmission of the encrypted message over a classic channel is simulated, and the Receiver entity proceeds to decrypt the received message. A final additional check is made by comparing the original message with the final message obtained after decryption, expecting full equivalence between both.

After running the protocol several times, various heat maps have been produced to represent data obtained from the simulations. For this experimental mode, several conditions were specified. The maximum length of the message, in number of bits, defines the x-axis in the heat map, taking positive integer values in increments of 10 units from 10 to that maximum. The value of the interception density step defines the y-axis of the heat map, taking \(\frac{1}{\text {step}}\) values between 0 and 1. The last parameter to specify is the number of repetitions for each generated instance of the problem. For each experiment, three color maps are generated. The examples shown Figs. 4, 5a and 5b, have been generated with the parameters of maximum message length taking the value 300, density step equal to 0.1, and 20 repetitions of each instance.

The first of these color maps is here called Security graph (see Fig. 4)). In lighter colors it shows the conditions (interception density and message length) in which there have been more occasions where the communication has been considered secure. In darker colors it indicates the communications in which more interceptions have been detected. In the simulations carried out, a tendency to obtain greater security of the protocol can be seen as the message length increases. This is so because in the executions represented on the left, the number of qubits is not sufficient to guarantee correct operation.

The second color map, here called Average correlation graph (see Fig. 5a), shows the value obtained by the average correlation for each generated scenario. In white are those cases in which it was impossible to calculate the correlation because they were messages with a lack of information in the data due to short length. It can be seen how slight variations, not too significant, lead to greater uniformity as the length of the message increases.

Finally, the Average correlation check graph (see Fig. 5b), shows whether the average correlation calculated in the previous graph meets the condition that guarantees secure communication (see Eq. (3)). Specifically, it is shown in blue when it is met, and in red otherwise. It is seen that when the message already has a relevant length, it remains stable, considering secure communications with approximately less than \(20\%\) of the interception density. This is because if Eve measures \(20\%\) of the transmitted qubits, it will only obtain approximately (\(0.2 \cdot \frac{2}{9} \approx 4.44\)) \(5\%\) of the information from Alice’s and Bob’s keys. The protocol manages to guarantee that, when this percentage of knowledge takes higher values, the communication is considered insecure, aborting its execution.

One year after the publication of the E91 protocol, Charles H. Bennett defined a QKD protocol called B92 [6], without using entangled pairs, but taking advantage of non-orthogonality properties. In fact, the B92 protocol can be seen as a simplification of the BB84 protocol [4].

This protocol requires n iterations to generate a random shared secret key that is about \(\frac{n}{4}\) bits in size. First, Alice randomly generates one of the two possible bit values 0 and 1, encodes it respectively with the orthogonal states \(|0\rangle\) or \(|+\rangle\), and sends this qubit to Bob. Bob then performs the measurement of the received qubit exactly as in the BB84 scheme, choosing randomly between the two possible bases: computational \(\{|0\rangle , |1\rangle \}\), or Hadamard \(\{|+\rangle , |-\rangle \}\). The bits for the key will be those corresponding to measurement results that uniquely determine actual values sent by Alice, which are identified here as “positive reading”. For greater clarity in the explanation of this protocol, Fig. 6 shows a graphic scheme of all possible measurement cases.

That image shows the two cases where Bob can be sure of the bit that Alice sent. On the one hand, if Bob chooses the computational measurement base and gets the \(|1\rangle\) then he is sure that Alice sent bit 1. On the other hand, if Bob chooses the Hadamard measurement base and gets the \(|-\rangle\) then he is sure that Alice sent bit 0. The rest of the cases are here called “negative reading” since with none of them Bob is certain about the bit sent by Alice. For that reason, those cases of “negative reading” are discarded. Thus, approximately \(\frac{3}{4}\) of the sent qubits will be discarded.

A detailed example is shown below, contemplating all the measurement possibilities. In this case, Alice sends the random \(|0\rangle\) state to Bob, which he can measure in two different ways:

The implementation of the B92 protocol carried out in this work was also integrated into the QuantumSolver library [12]. The class Participant creates an array of length n of random binary values to represent which values are transmitted by the class Sender and how they are measured by the class Receiver.

In the implementation, a 0 is added to the key only when Bob measures a \(|-\rangle\), and a 1 is added only when a \(|1\rangle\) is obtained.

The approximate probability that Eve will perform a “positive reading” of a sent qubit is exactly the same probability that Bob has of making a measurement that gives him one more bit of his key. This probability is shown in Eq. 4.In order for Eve not to be detected, she must make “negative reading” in each qubit she reads. However, this does not depend on her, but on the intrinsic quantum randomness that in 75% of the occasions will play against her. Otherwise, she could be easily detected. To simulate the attacker, the Eavesdropper entity was modified to perform intermediate measurements on the two possible bases. Thus, cases of “positive reading” are randomly generated with a probability of 25%, in which Eve knows perfectly the qubit to send, having performed a transparent reading without being detected. The cases of “negative reading” are generated with a probability of 75%, in which Eve does not know if she has measured in the wrong base. Even so, in these cases Bob has to measure with the opposite basis to that of Eve, i.e. the basis used by Alice, and obtain a false “positive reading” (25% of all Eve’s erroneous measurements). An example of this case can be seen in Fig. 7.

Several simulations have been conducted to generate heat maps, which represent the data obtained from the protocol. To perform this type of experiment, specific conditions were established in the same way as in the E91 protocol Security Graph. The heat map’s horizontal axis is determined by the maximum message length, measured in bits, and ranges from 10 to the maximum value, in increments of 10. The vertical axis is determined by the interception density step, which takes values between 0 and 1 in increments of \(\frac{1}{\text {step}}\). The final parameter that must be specified is the number of times each problem instance is repeated. After each experiment, the Security Graph is created.

The heat map in Fig. 8 was generated using the following parameters: a maximum message length of 300 bits, a density step of 0.1, and 20 repetitions for each instance. Lighter colors indicate situations in which communication has been considered secure more frequently. Conversely, darker colors indicate situations where more interceptions have been detected. This color gradient is determined by both interception density and message length conditions. It can be seen how a curve tending to zero is obtained very quickly. This demonstrates the safety of the protocol even with very few qubits, since there is only an error in those cases with insignificant numbers of qubits.

For a better visualization of the curve, another graph has been generated (see Fig. 9) focusing on shorter messages with a higher number of repetitions and steps. For this, 10-bit jumps in the message length were implemented. The variables took the following values: a maximum length of 70 bits, a density step of 0.05, and 30 repetitions for each instance.