Qerberos: A Protocol for Secure Distribution of QRNG Keys

A communication protocol for the distribution of cryptographic keys generated by a quantum random number generator (QRNG) has been developed by introducing a minor modification to Kerberos and using SRP as the authentication mechanism. The protocol, named Qerberos, allows two users to acquire the same symmetric key generated by a trusted third party with access to a QRNG, whose keys have higher entropy than a classical generator. An implementation that employs two different Q RN Gs has been tested for different parameters achieving good performance and short request times.


I. INTRODUCTION
Cryptography is an essential tool in communications nowadays, since it ensures confidentiality and authentication between peers. Common encryption and decryption algorithms use secret keys that should not be revealed to unauthorised users. The quality of these secret keys is of the utmost importance: they should possess the highest level of entropy possible to avoid brute-force attacks [1]. Classical Random Number Generators (RNG) generate low quality keys, and some of them have known vulnerabilities in their source code [2], which may jeopardise the entire communication. If an attacker manages to obtain the secret key (possibly via guessing or exploiting those vulnerabilities), she would be able to decrypt any message sent, regardless of whichever encryption algorithm is being used. This poses a serious problem: even if an algorithm is perfectly secure, the entire system may be in danger if low entropy keys are used.
Quantum Random Number Generators (QRNG) present a solution to this problem, since the randomness they provide is guaranteed by the laws of physics. However, this technology is currently in its first steps and QRNG devices have still a limited availability. Since keys could only be generated in specific locations with access to a QRNG, a method to securely distribute keys to users that require them is needed.
In this paper, we present a protocol which allows distributing secret keys generated by a QRNG to two users, so that the keys can be used as symmetric keys to establish their The work is funded by the Plan Complementario de Comunicaciones Cuánticas, Spanish Ministry of Science and Innovation(MICINN), Plan de Recuperación NextGenerationEU de la Unión Europea (PRTR-C17.I1, Ref. 305.2022), and Regional Government of Galicia (Agencia Gallega de Innovación, GAIN, Ref. 306.2022) This publication is part of the project TED2021-130369B-C31, TED2021-130369BC32, TED2021-130369B-C33 funded by MCIN/AEI/ 10.13039/501100011033 and by "ERDF A way of making Europe". secure communications. To that end, we propose a modification to the authentication protocol Kerberos [3], allowing the Service Granting Ticket (SGT) to contain two copies of the symmetric key encrypted with both users' session keys. Furthermore, Kerberos authentication has been modified to use Secure Remote Password (SRP) [4], an authentication protocol which does not require users to reveal their passwords. The new protocol (named Qerberos) has been implemented in Java using the Apache Kerby library [5]. The distribution of high-quality cryptographic keys could enhance security in critical processes where communications confidentiality and integrity is specially relevant. Moreover, since authentication is required to obtain a key, it could be used as a token to verify an user's identity during multi-factor authentication. Point-to-point communications, like instant messaging apps or file sharing, could also benefit from the additional security provided by QRNG-generated symmetric keys. Two different QRNG have been employed in this project, which will be introduced in Section II.
The protocol that we present in this document is novel, because it uses classical communication channels to distribute secret keys generated by a QRNG. Embedding SRP in Kerberos is mentioned in [6], and in [7] a zero-knowledge authentication algorithm for Kerberos is proposed. The authors of [8] propose an authentication method resistant to dictionary attacks for Kerberos. In [9], a multifactor authentication is incorporated in Kerberos. To the best of the authors' knowledge, no other reference to a Kerberos implementation with a zero-knowledge authentication algorithm exists in the literature.
The remainder of the paper is organized as follows. Section II describes the basic properties of QRNGs. The system architecture is presented in Section III, followed by a brief review of Kerberos. Section IV presents the novel Qerberos in detail, and a security analysis is provided in Section V. The protocol implementation is summarized in Section VI, and some concluding remarks appear in Section VII.

II. QRNG
Commonly used Pseudo Random Number Generators (PRNGs) generate pseudo-random numbers in a deterministic manner, starting with a seed and performing mathematical operations to produce an output. Because of this, an attacker would only need to know the seed to reproduce the secret key. A common practice is to use the current system time as the seed, which may make it easy for attackers to guess. Furthermore, implementation errors in the PRNG's source code may result in low entropy, easily predictable, secret keys.
TRNGs (True RNGs) exist to amend these vulnerabilities because they extract randomness from the environment, generating higher entropy keys in the process. TRNGs are very diverse [10], and can extract randomness from multiple sources such as signal noise or voltage fluctuation. TRNGs usually need to establish a threshold to determine whether the output should be "0" or "1". This threshold is difficult to determine in advance, but it is crucial for the TRNG's security: if incorrectly defined, an imbalance may appear between the empirical frequency of 0s and 1s. Moreover, changes in environmental conditions (e.g., temperature) may require a re-calibration of this threshold, which attackers might be able to exploit [11].
QRNGs [10]- [12] are a type of TRNG that extract randomness from the behavior of quantum particles, which are intrinsically random by our understanding of the laws of physics. Fig. 1 shows the structure of a QRNG: a light source emits photons directly into a sheet. Photons either bounce or pass through this sheet, and they do any of these actions with equal probability. It is impossible to predict whether a photon will bounce or pass through. We can assign a 0 to the event of passing through and 1 to bouncing. Repeating this action multiple times can produce an arbitrarily long output.
For this work, two different QRNGs have been employed: 1) IDQuantique's "Quantis QNRG USB": This device is accessible via an USB interface, and its manufacturers provide an API for multiple programming languages. Its key generation rate is about 4 Mb/s.
2) Centro de Supercomputación de Galicia's (CESGA) QRNG module: This supercomputer has a native QRNG infrastructure that can generate keys at 400 Mb/s. A remote SSH connection is required to gain access to this high-rate source, but at the expense of overhead for the transfer The performance with these two QRNGs will be compared n Section VI-C.

III. KERBEROS
Due to the current state of technology QRNGs are not yet widespread, and it would be infeasible to assume each user has access to one. QRNGs will likely be available at predefined locations, so establishing a protocol to securely distribute keys generated in these locations to users becomes necessary. As a result, the node tasked with generating the secret keys gains importance. It should be implicitly trusted by users, since it will have access to the secret keys it issues. In contrast, the key generation node will not trust users and will demand authentication from them. In this way, trust will be transitive: if Alice authenticates herself to the key generation node and obtains some credentials in return, she will be able to use these credentials to prove her identity to other users.
The proposed system architecture involves the following entities, as shown in Fig. 2: • Central Entity: generates random keys using a QRNG and distributes them on demand. Users are required to authenticate themselves, and the Central Entity provides them with a proof of identity. • Initiator: requests a random symmetric key, indicating which user he wants to communicate with. • Responder: receives a symmetric key from the initiator. To fulfil the requirements, we have designed a protocol inspired in Kerberos [13]. A Central Entity exists in this protocol, which demands authentication and distributes cryptographic material: the Key Distribution Center (KDC). To gain access to a service, a Client must perform two different interactions: Authentication and Service Request.

A. Needham-Schroeder Protocol
Kerberos is based in the Needham-Schroeder protocol [14], which manages to distribute a secret key to two peers from a trusted third party, the Authentication Server (AS). The AS must have established a secret key with both users Alice and Bob prior to the execution. The protocol is executed as follows: 1) The AS generates a key SK.
2) The AS sends Alice the key SK encrypted with the key they share, and also another copy of SK encrypted with the secret key between the AS and Bob. 3) Alice extracts SK and sends Bob the other copy of SK. 4) Bob extracts SK. 5) Both peers confirm they have the same key by sharing a random number.
This process happens multiple times in Kerberos, since the KDC generates keys and distributes them to users. The messages the KDC sends contain two copies of the same key: one of them accessible by the client, and the other encrypted in a Ticket that only another server can decrypt.

B. Authentication Exchange
In Kerberos, the first interaction clients preform with the KDC is the authentication. To that end they must communicate with an entity called Authentication Server, which is part of the KDC. The Authentication Server must storage users' information, including their passwords. The messages sent in this exchange are [13]: • KRB AS REQ: contains the client request and preauthentication information. • KRB AS REP: response from the AS. Contains the user's session key K a encrypted with his password's hash, which the AS knows. It also includes a Ticket-Granting Ticket (TGT) with another copy of K a , encrypted with a key known only by the KDC. Other authentication methods in Kerberos, such as Public Key Certificates [15], were not considered relevant for this work.

C. Service Request Exchange
Once clients obtain the TGT and K a they can perform a Service request exchange. To that end they must establish communication with the Ticket-Granting Service (TGS), which will authorise them to communicate with a Service Server. The exchanged messages are: (1) KRB TGS REQ: sent by the client. It includes the TGT (the TGS can decrypt the TGT, since it was encrypted with a key known by the KDC) and a timestamp encrypted with K a . It also includes the name of the service the client wants access to; (2) KRB TGS REP: response from the TGS contains a symmetric key K ap encrypted with K a , and a Service-Granting Ticket (SGT) with another copy of K ap , encrypted with a key known by the Service Server.

IV. THE QERBEROS PROTOCOL
As mentioned, the objective is to distribute a secret key generated by a QRNG, located in the KDC. To achieve this, a modification to Kerberos has been devised: instead of encrypting the SGT with a key known only to the Service Server, the session key of another user is chosen. This way, clients can obtain two copies of a symmetric key encrypted with two different session keys. By sending the SGT to the selected user, they can extract the same symmetric key and use it for secure communications. In brief, a client Alice can point out in message KRB TGS REQ that she wants a symmetric key with client Bob. The KDC will use the QRNG to generate two copies of K ab and send them to Alice in message KRB TGS REP. Instead of encrypting the SGT with the key of a Service Server, Bob's session key K b is used. The protocol defined above has been named Qerberos.

A. Protocol Definition
The communication scheme is shown in Figure 3. The steps are the following: 1) Alice performs authentication. 2) The KDC sends Alice her session key K aq encrypted with K a (derived during Alice's authentication). She also receives a TGT for future requests. 3) Bob performs authentication. 4) The KDC sends Bob his session key K bq encrypted with K b . He also receives a TGT. 5) Alice request a symmetric key, including Bob's identity in the message, and sends the TGT received in Step 2. 6) The KDC generates a symmetric key K ab with the QRNG. It sends to Alice a message encrypted with K aq including: (1) Bob's identity; (2) the symmetric key K ab ; (3) a Ticket encrypted with K bq including K ab and Alice's identity. 7) Alice extracts K ab from the message. She sends the Ticket to Bob. 8) Bob extracts K ab from the Ticket. He generates a nonce N b and encrypts it with K ab . 9) Alice decrypts N b and calculates N b -1. She encrypts the result with K ab and sends it to Bob, proving she knows the symmetric key.

B. SRP
As mentioned in Section III-B, the KDC must know the clients' password to perform authentication. In message KRB AS REP, the session key is encrypted with the NTLM hash of the client's password. This makes Kerberos vulnerable to dictionary attacks [6], allowing attackers to guess clients' passwords and, consequently, their session keys. Since the objective in Qerberos is to distribute symmetric keys securely, having such a point of failure may jeopardise the entire communication process.
To avoid dictionary attacks, Qerberos includes an alternative authentication method in which the Secure Remote Password (SRP) [4], [16], [17] algorithm is used. With SRP, clients can authenticate themselves without ever revealing their password to the authentication server. As usual for authentication protocol, a registration phase is required prior to the authentication. In Figure 4 the complete authentication process of SRP is shown, where parameters N , g and k are public.

1) In the registration phase, Alice randomly generates salt.
She calculates x with the salt and her password, and generates the verifier. 2) Alice sends the verifier and salt to the AS. she immediately destroys x, since its possession is equivalent to knowing the password.
3) The AS stores salt and the verifier in its database. 4) In the authentication phase, Alice randomly generates a private value a and a public value A. 5) Alice sends her identity and A. 6) The AS recovers salt and the verifier from the database.
It randomly generates b and B as private an public values (using k and the verifier), and uses A to calculate the shared value S. 7) The AS sends Alice B and salt. 8) Alice recalculates x with salt and uses B to generate S. At this point, both participants share the same S, so they both obtain the key K = H(S).

C. Incorporating SRP in Qerberos
Kerberos' password-based authentication has been replaced by SRP. This algorithm fits perfectly in Qerberos, since a shared key is generated during the authentication process that can be used to encrypt the session key, instead of the hash of the user's password. The number of messages sent have been limited to 2, so they fit inside KRB AS REQ and KRB AS REP. The field PA DATA of both messages allow for the inclusion of Alice's public key A in KRB AS REQ and the salt and the AS' public key B in KRB AS REP. The SRP protocol specifies two other messages where values M1 and M2 are sent, with the goal of proving that both peers know the shared key K. This is not necessary in Qerberos: if Alice does not know K she would not be able to obtain her session key, preventing her from requesting a key to the TGS.

V. SECURITY A. Security of Qerberos
The security of Kerberos, on which our system relies, has been formally analysed in the literature [18], [19]. The modifications applied to it do not invalidate those demonstrations, since they do not substantially alter Kerberos' cryptographic operations. Furthermore, in these analysis it is assumed that the key used to encrypt the session key in KRB AS REP is not vulnerable to dictionary attacks, which does not apply to the way Kerberos commonly handles authentication (using the hash of the user's password). Our Qerberos avoids this problem by using SRP as authentication method. Concerning the Qerberos protocol security, the solution provides: • Authentication: A trust relationship is established between Alice and Bob via the AS. When Bob receives a Ticket encrypted with his session key, he can be sure that it was generated by the AS, since it is the only other node that knows K bq . Bob can trust any information inside this ticket, including Alice's identity. • High entropy keys: both the symmetric keys and the session keys are generated by the QRNG. Because of this, keys have higher entropy that those generated by a deterministic RNG and thus they are harder to guess. We argue next that Qerberos is not less secure than Kerberos. The change to the authentication method eliminates Kerberos' main vulnerability: dictionary attacks [20]. The SRP protocol used in Qerberos does not directly use the hash of the client's password, so it is much difficult for an attacker to obtain his key. Moreover, key session quality is also notably higher in Qerberos, since Kerberos does not specify how these keys are generated, so they could be created by an insecure PRNG. Qerberos generates both the symmetric keys and the session keys via a QRNG, assuring a high level of entropy for the cryptographic material.

B. Security of SRP
Using SRP as authentication method substantially increases Kerberos AS exchange's security. The main advantages are: 1) Password Privacy: contrary to standard Kerberos authentication, the SRP protocol does not require the KDC to know users' passwords. Furthermore, no message exchanged during authentication contains any password, hash or secret value. Only public parameters, like the Client and AS' public keys or the salt, are sent. Thus, it is not necessary to establish a TLS tunnel to send private information during authentication.
2) Perfect Forward Security: the authentication system used in Kerberos always uses the same key to encrypt the session key. Therefore, if any attacker manages to obtain the user's password at any point, they would be able to decrypt the session key for every Kerberos authentication the client has ever performed with that password. Since SRP uses different keys for every authentication that depend on the creation of the short-lived private parameters a and b the leakage of a password will not endanger past communications.
3) Protection against dictionary attacks: when using SRP as authentication method, the key used to encrypt the session key does not directly depend on the user's password, as it does in standard Kerberos authentication. To perform a dictionary attack, a malicious user would need to access both the salt and the verifier, of which only the former is publicly transmitted. The former is stored at the database and never leaves the KDC after registration phase.

VI. IMPLEMENTATION
An implementation of the Qerberos protocol has been made using Apache Kerby [5], a Java library that implements Kerberos. Three different software agents have been created, representing the three entities that take part in the protocol: Authentication Server, Initiator and Responder. The first acts as the KDC server while the other two are Kerberos clients.

A. Authentication Server
An application assuming the role of the KDC server has been implemented. The following modifications have been applied to Apache Kerby to achieve the goals defined by the Qerberos protocol: 1) Session key storage: the Qerberos protocol requires the AS to store users' session keys, as it employs these keys to encrypt Tickets inside TGS replies.
2) SGT generation: in Kerberos, SGTs are encrypted with a Service Server private key. As mentioned, in the proposed scheme these Tickets are encrypted instead with the session key of a responder, chosen by the initiator in KRB TGS REQ.
3) User credential storage: the use of SRP as the authentication method allows the KDC to only store the salt and the verifier in its database, instead of any password hashes.

4) Authentication:
The session key sent in KRB AS REP is no longer encrypted with the hash of the user's password. Instead, the shared key generated at the end of the SRP protocol is used.
Both QRNGs have been incorporated to the Qerberos AS program. Communication with IDQuantique's QRNG is performed via their API, while keys generated by CESGA's QRNG are stored in a buffer to avoid continuous remote connections. Generated keys have a default size of 32 bytes, since well-known symmetric encryption algorithms like AES-256 use keys of this size. As mentioned in Section VI-C, key generation is not expected to establish an upper limit in the KDC's response speed.

B. Application Client
An API to allow other applications to act as a Qerberos client has been implemented. The API implements functions to perform authentication and request symmetric keys. It has been programmed in Java, so it can be used both in Android applications and desktop programs. Functions to distribute between initiator and responder also have been implemented,

C. Performance Tests
Tests have been executed to estimate Qerberos' performance and calculate the complexity order of its operations. The following functions have been analysed.
1) Authentication: 100 users have been generated for each of the different group sizes (i.e., size in bytes of the modulus N) in SRP authentication. The modulus values for each group size have been chosen following the recommendations in [4]. Results are shown in Table I: clearly, authentication time increases exponentially with the group size.
2) Key request: 1000 key requests have been performed for different key sizes, from 32 to 65536 bytes. While we expect key requests to rarely exceed 32 bytes since secure algorithms like AES-256 require keys of that length, we considered this experiment useful in finding the order of magnitude of this operation and comparing the performance of both QRNGs. Table II shows the results for Quantis QRNG. In order to better understand the allocation of time when using CESGA QRNG, key request time has been divided into three different operations: Qerberos protocol logic, SSH remote connection overhead, and QRNG key generation. Figure 5 plots the mentioned results, as well as total time. Qerberos and SSH times remain constant for most of the key sizes, but start to increase when the amount of information transferred through the network becomes big enough.
As evidenced by both results, request time increases linearly with key size. At key sizes below 1024 bytes, most of the time is spent in message processing and protocol logic, so key generation does not pose a limit to performance. However, when key sizes increase, time spent by the QRNG becomes the main factor. It is also shown that authentication is notably more expensive than key requests for recommended parameters (group of size 256 bytes and key length of 32 bytes). This is acceptable since a client only needs to perform authentication once to request any number of keys. Table II and Figure 5 show that in situations where less key material is required (i.e., small number of users, short keys requested), Quantis QRNG provides better performance. However, as demand for key material increases, CESGA QRNG's remote connection overhead becomes less significant and its high key generation rate makes it much more efficient than Quantis QRNG.

VII. CONCLUSIONS
In this paper, we have presented a novel key distribution system that allows pairs of authenticated users to obtain high quality, QRNG-generated cryptographic material. This protocol provides authentication between clients relying on certificates. Using SRP provides a meaningful increase in privacy, and avoids password-guessing attacks. Our performance tests show that Qerberos is able to distribute secure keys with very little overhead for clients. For both QRNGs, key generation time is negligible for reasonable key sizes, with CESGA's QRNG providing a much higher key rate in exchange for the overhead of establishing a remote connection.
Possible applications of Qerberos include, for instance, (1) Use in well-known communication protocols like TLS or IPsec as pre-shared keys. (2) Peer-to-Peer communications. Qerberos successfully distributes the same key to two different users. Thus, private communications with high quality keys between peers could be easily established. (3) High security environments. Qerberos can be employed to obtain highquality symmetric encryption keys. Furthermore, possession of a shared key obtained through Qerberos proves that a client has successfully performed authentication to the KDC; this key could be used to verify a user's identity during multifactor authentication.

A. Future Work
• Comparison with Kerberos. Measuring the performance and comparing the provided security level for both Qerberos and Kerberos would help to estimate the differences between these two protocols. Other key transmission protocols could also be compared to Qerberos.