# Quantum Key Distribution with Post-Processing Driven by Physical Unclonable Functions
## 2 Results and Discussion
### Large QKD networks
Given the current status of quantum technologies, however, the presence of a KDC in large networks facilitates and guarantees the generation and the distribution of pre-shared keys between users, which are essential for the establishment of the first secure pairwise QKD sessions. In the literature of QKD, the inclusion of a KDC is also considered essential for one more reason, namely, it can operate as a relay, thereby allowing two users that are separated by a distance well beyond the reach of current QKD systems to establish a secret key [6]. The ideas discussed in the previous subsection can be generalized in the context of large QKD networks if we assume that the KDC holds all the databases of CRPs, as shown in Figure 6. The manufacturer assigns a PUF tag to each QKD device (sender or receiver), and a separate database of CRPs is created along the lines discussed in the previous subsection. For the sake of simplicity, let us assume that the manufacturer of the QKD devices also controls the KDC, while the manager of the KDC has one PUF for each database, i.e., for  
Figure 5: Full-mesh QKD network involving \(n\) users. (**a**) In the absence of a key distribution centre (KDC), the total number of pre-shared keys is \(n(n-1)/2\), while each new user has to share \(n\) keys with each one of the other existing users. (**b**) In the presence of a KDC, each user shares a key with the KDC only. each user. So, the KDC manages as many databases and PUFs as the user devices in the QKD network. For the sake of concreteness, let us consider the database for the QKD device C, intended for [PERSON], who will join the QKD network. Let \(\text{PUF}_{\text{MC}}\) denote the PUF used by the KDC for the encryption of the entries in [PERSON]'s database of the CRPs. The \(j\)th entry in the database involves the challenge \(c_{j}\) and the joint key \(\mathbf{k}_{j}^{(\text{MC})}\oplus\mathbf{k}_{j}^{(\text{C})}\), where \(\mathbf{k}_{j}^{(\text{MC})}\) and \(\mathbf{k}_{j}^{(\text{C})}\) denote the keys associated with the responses of \(\text{PUF}_{\text{MC}}\) and \(\text{PUF}_{\text{C}}\) to challenge \(c_{j}\), respectively. As soon as [PERSON] is ready to join the network, his first task is to establish a common secret key with the KDC, following the steps discussed in the previous subsection. The procedure is recapitulated in Figure 6b, with the necessary changes in the labels. Figure 6: Integration of PUFs in a large QKD network. (**a**) Each QKD device (sender or receiver) is associated with a PUF. The PUF generates a random key as a response to a challenge. The KDC has its own PUFs, and it is controlled by the manufacturer, who creates a database of challenge–response pairs for each QKD device. The KDC has access to the databases of CRPs for all of the QKD devices that have been or will be connected to it, while a different PUF is used for the encryption of the entries in each database. (**b**) Each time that fresh key material is needed for a user, the user can generate a common random key with the KDC by running the protocol in the shaded box. Note that the presence of the QKD link between the KDC and the user is not necessary, as keys can be generated from the PUFs. In practice, the addition of such a QKD link will limit the distance between the user and the KDC, but it can make the network self sustainable in terms of key generation and consumption. Having established a common secret key with the KDC, [PERSON] can establish a common secret key with any other existing user in the network, which will allow them to run the post-processing in the first QKD sessions until a sufficiently large number of fresh secret random bits has been generated through the QKD. The procedure is outlined in Figure 7 and it is as follows. The key manager of the KDC shares a common secret key \(\bar{k}_{\text{M,C}}\) with [PERSON] and another key with [PERSON], a user who is already in the network and with whom [PERSON] wants to communicate.