Integrating Quantum Cryptography into SSL

INTEGRATING QUANTUM CRYPTOGRAPHY INTO SSL

Sufyan T. Faraj M IEEE, Associate Prof., College of Computers, University of Anbar, Iraq

Email: [email protected]

ABSTRACT It is well believed now that there are many advantages of integrating quantum cryptography (QC) with the already-existing Internet security infrastructure. SSL/TLS is the protocol that is used for the vast majority of secure transactions over the Internet. However, this protocol needs to be extended in order to create a promising platform for the integration of QC into the Internet infrastructure. In order to facilitate such type of integration, this paper presents a novel extension of SSL/TLS, which called QSSL (Quantum SSL). During the development of QSSL, a concentration has been made on the creation of a simple, efficient, general, and flexible architecture that enables the deployment of practical quantum cryptographic-based security applications. Indeed, QSSL efficiently supports unconditionally secure encryption (one-time pad) and/or unconditionally secure authentication (based on universal hashing). A simplified version of QSSL based on BB84 (Bennett-Brassard 84) quantum key distribution (QKD) protocol has been implemented and experimentally tested. This has enabled us to experimentally assess our protocol design based on software simulation of the quantum channel events used for QKD. Keywords: Quantum Cryptography, SSL/TLS, Unconditional security.

1 INTRODUCTION

Quantum information technology can support entirely new modes of information processing based on quantum principles. Indeed, there are many useful tasks in the field, such as quantum cryptography (QC), which involve only a few consecutive quantum computational steps. In such cases, the unwelcome effects of decoherence can be adequately diminished by improving technology and communication protocols.

Security with today's cryptography can usually be achieved on the basis of computational complexity. Thus, almost all cryptosystems can be broken with enormous amounts of calculations. In contrast, QC delivers cryptographic keys whose secrecy is guaranteed by the laws of physics. QC offers new methods of secure communications that are not threatened even by the power of quantum computers. Quantum key distribution (QKD) is already making its first steps outside labs both for fiber optic networks and also for satellite-based

communications. It is expected that within a decade, it will be possible to place sources of entangled photons on satellites. This would allow global quantum communication, teleportation, and perfectly secure cryptography [1].

While conventional methods continue to meet the more-demanding information security needs of our increasingly networked world, the face increasing technological challenges, such as [2]:

1- Unanticipated advances in mathematics, high-performance computing, and the possibility of large-scale quantum computations.

2- Increasing complex future requirements for secure network communications to support dynamically reconfigurable groups of users with multi-level security.

3- Projections for the ever growing bandwidth demands for secure communications.

It is well believed now that QC has the potential

to counter these threats and help to meet these

Special Issue of Ubiquitous Computing Security Systems

UbiCC Journal - Volume 5 www.ubicc.org 1778

Lab Computer

UbiCC Journal Logo

future requirements, if it can reach a stage of a sufficient maturity. Hence, in order to facilitate the evolution of QC towards a practical "quantum information security era" in which QC becomes more closely integrated with conventional information security systems and communication networks infrastructures, a more collaborated scientific research among specialists from several fields is required. In particular, this research activity has to bring together theoretical and experimental physicists, computer scientists and electrical engineers, and communications and information security specialists.

Throughout this paper, a focus is maintained on the subfield of QKD. QKD basically enables two parties (traditionally referred to as Alice and Bob) to produce the shared secret keys required for secure communications, through a combination of quantum and conventional communication steps. Today QKD systems can be operated over metro-area distances on optical fibers, and across multi-kilometer line-of-sight "free-space" paths. Thus, in addition to stand-alone point-to-point (PTP) systems, QKD can be integrated within optical communication networks at the physical layer, and with key-management infrastructures. However, there are several issues to be explored by research in this direction. Among these issues are [2]:

1- Investigation of network support concerns beyond PTP connectivity.

2- Integration of QKD with conventional cryptographic and secure communications infrastructures.

3- Exploration of system-level security attributes of QKD.

The work presented in this paper addresses all

of the above issues. It proposes a novel extension of SSL/TLS (Secure Socket Layer/Transport Layer Security) that we call QSSL (Quantum SSL). QSSL allows the integration of QKD capabilities within the Internet (or intranet) security architecture. This significantly facilitates applications in the environments of "QKD networks".

Some aspects of QKD networks have been recently addressed in the literature. The "world's first" QKD network that is composed of trusted relays and/or untrusted photonic switches had been continuously running since June 2004 under the sponsorship of the US DARPA [3], [4], [5], [6]. This network uses a modification of IPSec to integrate it with QKD.

In Europe, the SECOQC project has recently demonstrated information-theoretically secure QKD over a fiber-based MAN in 2008. In this project, a dedicated key distribution network infrastructure has been adopted. It is the so-called "network of secrets" [7], [8].

In [9], a performance analysis for a proposal that integrates QKD into IPSec was presented. Also, a scheme integrating QC in 802.11i security mechanisms for the distribution of encryption keys was outlined in [10]. Some issues of authentication and routing in simple QKD networks were addressed in [11], [12].

Despite that the use of SSL/TLS as the consumer of random secret bits obtained from QKD has been already suggested in [4] and [13], the author is not aware of any specific proposal or design explicitly dealing with the extension of SSL/TLS for QKD integration. To the best of author knowledge, this work represents the first explicitly proposed design and implementation of SSL/TLS extensions for use in various QKD networks.

2 QKD NETWORKS

In securing a PTP link, QKD can be used to achieve unconditional security over that link. In this case, keys established by QKD are used for one-time pad (OTP) encryption and for information-theoretically secure authentication (based on universal hashing). This unconditional security over the PTP link can be proven because of the fact that the security of QKD can be expressed in the framework of universal composability [7], [14]. This definitely is one of the most important applications of QKD.

Alternatively, it is possible to compose keys obtained from QKD with a classical computationally secure encryption scheme (such as AES). In this case, it would be possible to encrypt large rates of classical data over the PTP link. However, the final security of the data exchanged over such a link cannot be stronger than the security of the encryption scheme. Nevertheless, it is still possible to show that QKD has important advantages over other key distribution techniques in terms of key security and key renewal rate [2], [7].

In spite of these advantages obtained from applying QKD over PTP links, such an application also has important weaknesses. These include vulnerability to denial of service attacks, vulnerability to traffic analysis, distance- and location-dependence, and the insufficient key delivery in certain situations [3]. The recent work in building practical QKD networks is aiming to strengthen the performance of QKD in these weaker areas. Also, its goal is to overcome all limitations inherited by PTP links and to obtain the full advantages of networking environments.

It is possible to define a QKD network as an infrastructure composed of quantum links connecting multiple distant nodes that have the capability of performing QKD. Regarding the hardware of QKD networks, it is convenient to



characterize different QKD network models by the functionality that is implemented within the nodes. Thus, beyond stand-alone QKD PTP links, it is possible from this perspective to differentiate three main categories of QKD networks [3], [7]:

a) Optically switched QKD networks: In this category, some classical optical functions like beam splitting, switching, multiplexing, etc., can be applied at the network nodes on the quantum signals sent over quantum channels. These optical functions can be used to achieve multi-user QKD. One-to-many connectivity between QKD devices has already been demonstrated at gigahertz clock-rate over passive optical access networks [15]. Active optical switching can also be used to enable selective connection of any QKD nodes, as in DARPA network [6]. One important advantage of this category is that the corresponding nodes (which perform classical optical functions) need not to be trusted. However, due to the extra mount of optical losses introduced, this network model cannot be used to increase the distance of QKD.

b) Trusted relays QKD networks: In this category, local keys are generated over QKD links and then stored in nodes that are placed on both ends of each link. Global key distribution is performed over a QKD path, i.e. a one-dimensional chain of trusted relays connected by QKD links, establishing a connection between two end nodes. Hence, secret keys are forwarded in a hop-by-hop fashion along the QKD path. This concept of classical trusted relays can be used to significantly increase the distance of QKD, provided that the intermediate nodes can be trusted. Thus, this network model has been exploited by the DARPA QKD network and also adopted by the SECOQC network.

c) "Full" quantum networks: These are networks that aim to extend the distance of QKD by using "quantum repeaters", which can be used to an effective perfect quantum channel by overcoming propagation losses. In this scheme, it is not necessary to trust the intermediate network nodes. However, quantum repeaters cannot be realized with current technologies. In addition, it was shown in [16] that another form of quantum nodes called "quantum relays" can be used to extend the distance of QKD. Quantum relays are simpler to implement than quantum repeaters; however, they remain technologically difficult to build.

As far as the QKD network software is

concerned, we can notice that there are two main strategies that are globally considered in building practical QKD networks. It is possible to differentiate between them on the basis of the degree of dependence of the developed QKD

network software on the pre-existing conventional network security infrastructure. We shall name these two strategies as: tightly-coupled protocol stack strategy and loosely-coupled protocol stack strategy. They are explained as follows:

A. Tightly-coupled protocol stack strategy: In this strategy, secret random bits obtained from QKD (which is mainly a physical layer technology) are merged directly somehow into a conventional higher-layer security protocol suite. Thus, the consumer security protocol has to be modified to enable the integration of QKD within it. The work of DARPA QKD network is a good representative of such an approach where IPSec is used as the consumer protocol. Indeed, the work presented in this paper can also be considered under this category with SSL/TLS being used as the consumer higher-layer protocol. The advantage of this strategy is that it greatly facilitates direct implementation of QKD on private intranets (with an open possibility of a practical Internet implementation at some later mid-term stage). This is mainly because that we make use of already existing capabilities of networking and security protocols with some modifications.

B. Loosely-coupled protocol stack strategy: The focus here is to develop original multi-layer protocol infrastructures that are dedicated to QKD networks. In such a case, the QKD network infrastructure can be viewed as a "new cryptographic primitive" that is completely independent of the way by which random secret bits obtained from QKD would be used. This is the approach adopted by the SECOQC project. Of course, this approach may get the more of network environments by developing original routing and network management techniques. Hence, this strategy can be considered as a rather longer-term version of QKD networks.

3 SSL/TLS OVERVIEW

SSL was originally developed by Netscape. SSLv3 was designed with public review and input from industry [17]. Then, the TLS working group was formed within IETF (Internet Engineering Task Force) and published TLSv1.0 [18] that is very close to SSLv3 and can be viewed as SSLv3.1. Later, TLSv1.1 [19], which is a minor modification of TLSv1.0, had been proposed.

The "socket layer" lives between the application layer and the transport layer in the TCP/IP protocol stack. SSL/TLS (or just simply SSL) contains two layers of protocols. The SSL Record Protocol provides basic security services to various higher-layer protocols and defines the format used to transmit data. Also, SSL defines three higher-layer



protocols that use the SSL Record Protocol. These three protocols are used in the management of SSL exchanges. The first is the Change Cipher Spec Protocol, which updates the cipher suite (list of a combination of cryptographic algorithms) to be used on SSL connection. The second is the Alert Protocol that is used to convey SSL-related alerts to the peer entity. The third is the Handshake Protocol, which is the most complex part of SSL and it is briefly described later in this section.

An SSL connection is a transport (in the OSI layering model definition) that provides a peer-to-peer type of service. SSL connections are transient and each connection is associated with one SSL session. An SSL session is an association that is created by the Handshake Protocol. The session defines a set of cryptographic security parameters that can be shared among multiple connections. Thus, it is possible to avoid the expensive negotiation of new security parameters. Once a session is established, there is a "current" operating state for both read and write (i.e. receive and send). "Pending" read and write states are created during the handshaking. Then, upon a successfully completed handshaking, pending states become the current states.

The SSL Record Protocol provides the services of confidentiality and data integrity for SSL connections. On transmission, the SSL Record Protocol takes an application message, fragments it into manageable blocks, optionally compresses the data, applies a MAC (message authentication code), encrypts, adds a header, and finally transmits the resulting unit in TCP segments. On reception, received data are decrypted, verified, decompressed, reassembled, and then delivered to higher-level users.

Four content types are defined by the Record Protocol. These are the three SSL-specific protocols (change-cipher-spec, alert, and handshake) and application-data, which corresponds to any application that might use SSL.

The Handshake Protocol allows the two communicating parties (client and server) to authenticate each other. It also enables them to negotiate an encryption algorithm, a MAC, and cryptographic keys required to protect data sent in SSL. The Handshake Protocol consists of a series of messages exchanged by client and server, as shown in Fig. 1. This exchange can be viewed as having four phases [17]:

Phase 1- Establish security capabilities:

This phase is used to initiate a logical connection and to establish the associated security capabilities. It starts by a client-hello message and ends with a server- hello message. During this phase, the client and server negotiate the SSL version to be used, session ID, compression

method, and the cipher suite. They also exchange random structures to serve as nonces. A cipher suite defines a key exchange algorithm and a CipherSpec, which includes encryption algorithm, MAC algorithm, and some other related information. The exchange methods supported by SSL/TLS are: RSA, fixed DH (Diffie-Hellman), ephemeral (temporary) DH, and anonymous DH.

Phase 2- Server authentication and key exchange:

In the beginning of this phase, the server sends its certificate (if it needs to be authenticated). This certificate message is required for any agreed-on key exchange except anonymous DH. Next, a server-key-exchange message can be sent (if required). This message is not needed if an RSA key exchange is used or if the server has sent a certificate with fixed DH parameters. Then, a nonanonymous server can request a certificate from the client by sending the certificate-request message. Finally, this phase ends with a server-done message.

Phase 3- Client authentication and key exchange:

The client begins this phase by sending a certificate message (if the server has requested it). Next, it sends the client-key-exchange message whose purpose is to enable the client and the server to create a pre-master-secret. The content of this message depends on the key exchange method. The exchanged pre-master-secret is to be used later by both parties to calculate the shared master-secret, which is a 384-bit value that is generated for each session. Then, CipherSpec parameters are generated from the master-secret using a certain hashing technique. These parameters are a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV (initialization vector), and a server write IV. Finally, the client may send a certificate-verify message to provide explicit verification of its certificate.

Phase 4- Finish:

The client sends a change-cipher-spec message and copies the pending (CipherSpec) states into the current states (Note that this message is sent using the Change Cipher Spec Protocol). Then, it sends the finished message under the new algorithms, keys, and secrets. Finally, the server sends its change-cipher-spec, transfers the pending to the current CipherSpec, and sends its finished message.



Figure 1: Handshake Protocol Message Exchange.

If an SSL session exists, then the two

communicating parties share a symmetric secret-key that can be used to establish new SSL connections, thereby avoiding expensive public-key operations required for session establishment.

In two recent RFCs (Request for Comments), three new sets of pre-shared key (PSK) cipher suites have been defined for TLS. These PSKs are symmetric keys, shared in advance among the communicating parties. The first set of these cipher suites uses only symmetric-key operations for authentication. The second set uses DH exchange authenticated with a PSK. The third set combines public-key authentication of the server with PSK authentication of the client. Indeed, these PSK cipher suites may be used in an authentication-only mode, where they can offer authentication and integrity protection with no confidentiality [20], [21].

4 THE QSSL PROTOCOL

In this section, the Quantum SSL (QSSL) protocol is described. This is mainly done by describing the most important modifications and extensions introduced to the "conventional"

SSL/TLS. In the beginning, some important design issues of QSSL are presented as follows:

1- The choice of SSL/TLS: SSL has been chosen as the basic protocol for this work because it is a very widely used, relatively simple, and well-designed security protocol. In a comparison, IPSec has been always considered to be overly complex protocol that includes some significant flaws (see for example [22]). However, each of SSL and IPSec has its own relative advantages and disadvantages, which mainly come from their different functioning locations in the network protocol stack.

2- Simplicity and efficiency: During the development of QSSL, we have tried to introduce the minimum possible modifications and extensions to SSL that result in an efficient integration of QC within SSL. This approach also has enabled the avoidance of designing a completely new protocol, which may contain an expected security flaws. Indeed, this integration ha efficiently facilitated both of SSL and QC to get benefits from each other. On one hand, SSL can obtain fresh secret keys from QKD. On the other hand, the required classical public discussions of QC can be conveyed using SSL encapsulation.

3- Generality: QSSL is not directed towards a specific QKD protocol implementation. We have tried to make the extensions as general as possible such that different QKD implementations and phase components can be considered. Indeed, other QC protocols rather than QKD might also be considered in the future.

4- Traditional vs. unconditionally secure encryption: Each of the unconditionally secure encryption using OTP and traditional encryption (such as 3DES, AES, etc.) has its own advantages and requirements. Hence, QSSL supports both types of encryption (Note that "conventional" SSL/TLS does not support OTP).

5- Message authentication: Traditionally used MACs can only offer computationally-secure data integrity. But authentication codes based on universal hashing may offer unconditionally-secure data integrity. However, these authentication codes need secret bits to be initially shared by authorized parties. As QKD can be used as a source for these bits, QSSL supports both types of message authentication for the data traffic. This introduction of the service of unconditionally-secure data integrity for the application traffic might be one of the important novel aspects of QSSL. Note; however, that this feature is apart from the mandatory use of unconditionally-



secure authentication codes for protecting public channel discussions of QKD.

6- Network initialization: To achieve unconditional security (which is the main reason for the deployment of QKD networks), QKD networks need initially pre-distributed secret keys. These keys are required to perform the first rounds of unconditionally-secure authentication for the QKD public channel. However, there is another possibility of using public-key cryptography for the initialization of the network by authenticating only the first rounds of QKD. Then, unconditionally-secure authentication can be used for subsequent QKD sessions. Despite the fact that such kind of hybrid authentication and network initialization technique does not offer unconditional security in a strict sense, they still present a security advantage over any other conventional key distribution technique, as argued in [7]. Thus, both of these QKD network initialization modes are supported by QSSL.

7- Applicability: In a contrast with classical open networks (such as the Internet), QKD networks can be considered as "closed" networks, especially at this early development stage. This is mainly due to the physical limitations they have. Thus, QSSL is more suitable (at least for the time being) for application in private intranets rather than the public Internet. However, as such private networks are already used by many organizations; the deployment of QSSL would bring a considerable security advantage for these intranets.

Various aspects of QSSL are described in the

following subsections. Note that for a reason of clarity, QSSL handshake is described as two modes. Mode-1 is based on the traditional public-key initialization of SSL/TLS. Mode-2 is based on PSK cipher suites. Otherwise, it is straight forward to only describe a single QSSL handshake mode by just labeling some messages as situation dependent and specifying the use of suitable cipher suites. The protocol version to be initially used for QSSL is 3.5 (remember that SSLv3 uses 3.0, TLSv1.0 uses 3.1, and TLSv1.1 uses 3.2).

4.1 Introducing a new SSL/TLS content type

A fifth content type is introduced for the SSL Record Protocol. This new type is to be called quantum-cryptography and it is related to any QC protocol to be integrated within SSL/TLS. By defining this content type, the QC protocol (e.g. QKD) is to be considered as an additional higher-layer SSL/TLS protocol just like the Handshake, the Change Cipher Spec, and the Alert protocols. The message format of the QSSL Quantum

Cryptography Protocol is shown in Fig. 2. Each message of the Quantum Cryptography Protocol has the following fields:

Figure 2: Message Format of the QSSL Quantum Cryptography Protocol.

• Type (2 bytes): Indicates one of the messages

used in the public exchange phase of the QC protocol. Some of the messages defined for QKD are listed in Table 1.

• Protocol (1 byte): The QC protocol used (e.g. the BB84 QKD protocol due to Bennett and Brassard [23]).

• Version (1 byte): Enables the use of more than one version of a certain QC protocol. Thus, components of different characteristics can be used to implement any phase of that protocol. For example, different techniques for sifting, reconciliation, estimating eavesdropper's (Eve) information, and/or privacy amplification may be used for implementing the BB84 protocol.

• Length (4bytes): The length of the message in bytes.

• Job no. (2 bytes): Enables the operation of multiple QC protocol jobs (or instances), all belonging to a one QSSL session.

• Authentication (1 byte): Indicates whether this message is authenticated. It may also contain some additional information about this authentication (if any).

• Encoding (1 byte): Indicates if a certain encoding technique is used for the content field of the message. It may also contain some additional information about this encoding (if any). For example, a form of run-length encoding is used for the (sparse) messages of the QKD sifting phase.

• Content ( ≥ 0 bytes): The parameters and data associated with this message. Table 1 contains some representative contents of QKD messages.

• Tag: If the message is authenticated, this field would contain the corresponding authentication tag. Its size depends on the used authentication code.



Table 1: QKD Protocol Message Types.

4.2 Defining new cipher suites Here, two new sets of cipher suites are defined

to be used for QSSL. The first of these sets uses public-key cryptography to initialize the QKD process. This set is to be applied whenever there is no possibility for authorized users to initially have PSKs required for universal hashing. This set may also be used when users believe that the security offered by such cipher suites is adequate for them. This situation represents what we call QSSL Mode-1. The second set of cipher suites uses PSKs to facilitate the use of unconditionally-secure authentication for protecting the QKD public channel. This set can offer provable security and it corresponds to the second mode of QSSL handshaking (QSSL Mode-2).

Table 2 lists some representative examples of these two sets of cipher suites. In this table, the first three cipher suites belong to the first set just described above, while the last three cipher suites belong to the second set. To increase the flexibility of using different software components in implementing QKD, two distinct implementations of BB84 (BB84 version 1 and BB84 version 2) have been assumed to be available to each user. Indeed, in this table, UHASH1, UHASH2, and UHASH3 represent three different unconditionally-secure authentication codes (such as Wegman-Carter scheme [24], Taylor scheme [25], etc.).

As far as the first set of cipher suites is concerned, network initialization can be done using any of following "conventional" SSL/TLS key exchange methods, which are: RSA, fixed DH, or ephemeral DH (DHE). However, the use of anonymous DH key exchange is not supported by QSSL because it makes the system vulnerable to man-in-the-middle attacks. Furthermore, this set can only use traditional MACs (such as SHA and MD5) for protecting the QKD public channel. This is obviously due to the assumption unavailability of PSKs required for unconditionally-secure authentication. In contrast, the second set of cipher suites always use unconditionally-secure

authentication for protecting QKD public channel discussions. This is implied by using PSKs for system initialization in this latter mode.

It is very important to notice that both sets of cipher suites support the use of traditional encryption algorithms and OTP. Also, they both support either traditional MACs or unconditionally-secure authentication codes to offer data integrity for QSSL application traffic (as clearly indicated by the last two columns in Table 2). This is totally justified since both sets are defining QKD to supply the required secret bits.

4.3 Cryptographic computations

QSSL uses QKD to directly generate the following cryptographic parameters: client write MAC secret, server write MAC secret, client write key, server write key, client write IV, server write IV, and pre-master-secret. Note that we have used the same terminology of SSL/TLS. However, the write MAC secrets are used in the generation of both of traditional and unconditionally-secure message digests. Similarly, the write keys are used for both traditional and unconditionally-secure encryption. The write IVs are only generated when traditional block ciphers are used for encrypting application traffic. Whenever unconditionally-secure encryption and/or authentication are to be used, the size of the required write keys and/or the size of the required write MAC secrets have to be negotiated during QSSL handshake.

Table 2: Some QSSL Ciphersuites.

The pre-master-secret generated from QKD is

divided into two parts. The first 48 bytes of it compose the first part, which we call pre-master-secret-1. The remaining bits of the pre-master-secret compose the second part that is to be called pre-master-secret-2. Then, the master-secret is calculated from pre-master-secret-1. The function used for calculating the master-secret in QSSL is similar to that used by SSL/TLS. Next, the master-secret can be used for authenticating the finished



handshake messages and for resuming QSSL sessions (when it is allowed). QSSL sessions can be resumed if and only if both of encryption and message digest algorithms used for application traffic are not unconditionally-secure. Otherwise, connections cannot be generated from sessions because this can be fatal for the specified property of unconditional security.

The pre-master-secret-2 is to be used as a PSK for initiating future QSSL sessions. Hence, its size has to be negotiated by users during handshaking such that its size is adequate to enable the use of unconditionally-secure authentication for protecting the QKD public channel. Note that this separation of the pre-master-secret into two independent parts is necessary from the respective of unconditional security.

4.4 QSSL Mode-1

This mode represents QSSL handshaking based on using public-key cryptography for initialization. Any of the traditional SSL/TLS key exchange techniques (except for the anonymous DH) can be used. The sequence of message exchange of QSSL Mode-1 is very similar to that of SSL/TLS described previously in Section 3. However, there are some required modifications to be noted. The most important of these are:

1- At least three new parameters should be added for negotiation in the client-hello and server-hello messages. These parameters are the size of write MAC secrets, the size of write keys, and the size of the pre-master-secret. The first of these is to be added whenever unconditionally-secure authentication is required for QSSL application traffic. The second parameter is included when it is intended to use OTP encryption. Finally, the third parameter is added whenever users have the intention to generate PSKs for future Mode-2 initialization (The size of this parameter should be ≥ 48 bytes). Note that this point also applies to QSSL Mode-2.

2- QKD (or generally any QC protocol) can only be started after both sides mutually authenticate each other. Also, QKD has to be finished before exchanging any change-cipher-spec message. Hence, the whole QKD message exchange is inserted between Phase 3 and Phase 4 of SSL Handshake described previously.

3- QKD continues until the complete generation of the negotiated key sizes. After this point only, change-cipher-spec and finished messages (Phase 4) can be exchanged (This issue also applies to QSSL Mode-2).

4.5 QSSL Mode-2 This handshaking mode uses PSK based

initialization. This offers a very high speed session initialization compared with the relatively slow public-key cryptography based Mode-1 initialization. Fig. 3 shows the basic Mode-2 message exchange. QKD message exchange is also is completely inserted just before the transmission of change-cipher-spec and finished messages.

Besides the three security parameters added to the negotiation by the client-hello and server-hello messages mentioned previously, there is an important modification to server-key-exchange and client-key-exchange messages in this mode. In QSSL Mode-2, these two messages are used for identification and synchronization of PSK pads. At first, the server-key-exchange message is used to carry a "PSK identity hint". One possibility for this "PSK identity hint" is to be a hash value of some bits from the beginning of the PSK pad. This may also be accompanied by some sort of a sliding-window technique to discard some (unsynchronized) bits from the beginning of pads.

The client-key-exchange message, when received, is to be interpreted as a positive acknowledgement of the "PSK identity hint". Otherwise, an unknown-psk-identity alert message has to be sent by the client.

4.6 Key pads management

Basically, QSSL can be considered to be a protocol that uses QKD to supply users with on-the-fly cryptographic keys. This is accepted a far as the write keys and write MAC secrets are used directly after their generation for protecting application data traffic. In this case, only PSK pads (when generated) need somewhat a loner-term management.

However, it is also possible to use QSSL in a key-store operation mode, wherein all keys are generated in much larger sizes and stored for future usage. This requires the development of management and synchronization mechanisms for five key pads per user (one pad for each of the five keys generated from QKD). This number would be duplicated considering any additional security relation with a new user. At this stage of QSSL, we believe it is not a good practice to include such mechanisms within QSSL. It might be better to develop such mechanisms out-of-band. However, this issue could be re-considered in a future QSSL version.



Figure 3: QSSL Mode-2 Handshake.

5 SYSTEM ARCHITECTURE

The system architecture of a typical QSSL application is shown in Fig. 4. As the figure indicates, QSSL is located between application layer protocols and TCP. On transmission, QSSL accepts data traffic from the application layer and adds the required security protection before sending it down to lower layers. The BB84 is used as the QC protocol in this architecture. QSSL uses the network to send two types of traffic. The first is application data traffic, which is encrypted and authenticated according to user's requirement. The second is the traffic corresponding to the classical public channel exchanges required for implementing BB84. This latter traffic type is transmitted during QSSL handshake and it has to be authenticated in order to defeat man-in-the-middle attack on the QKD protocol.

Figure 4: System Architecture for a Typical QSSL Application.

The quantum transmission phase of BB84 is

done using the quantum channel. This is mainly a physical layer technology. Hence, management and control of this phase is performed at the lower layers of the architecture. Other phases of BB84 (namely sifting, reconciliation, estimating Eve's information, and privacy amplification) uses the classical public channel for the required discussions. These phases are implemented using a specific user-mode application module that we call BB84 QKD protocol engine. The input of this engine is raw quantum bits resultant from quantum transmission, while its output is secret bits that are (temporarily) stored in the key storage and management module. These bits are used by QSSL as cryptographic keys in accordance to the specified cipher suites.

A simplified version of QSSL has been implemented based on Microsoft "WinSock" technology using Visual C/C++ v.6 with system running under Windows XP. This QSSL implementation has been integrated with our previously developed BB84 protocol engine [26]. This protocol engine is based on software simulation of the BB84 physical layer. It also includes a suitable code for performing other BB84 phases. The required unconditionally-secure authentication for BB84 public channel communications has been achieved according to our previously developed authenticated version of BB84 [27]. This authenticated BB84 implementation uses Taylor's authentication code [25] for obtaining unconditionally secure authentication tags.



The experimental setup consists of two QSSL instances installed onto two PCs (each with 1.7 GHz Intel Pentium IV processor). These two PCs are connected via an Ethernet. Sample results showing the amount of net key expansion gain for different QSSL sessions are illustrated in Figure 5 and Figure 6. In these two figures, all QKD sessions have been performed at a quantum bit error rate (QBER) of 5%. Also, 20% of sifted bits have been used for public comparison to estimate the amount of QBER. This estimation is required to set the parameters of the reconciliation phase and to decide whether to proceed with the QKD protocol or not. Eve's information about the cryptographic keys generated from all QKD sessions has been reduced well below 10-70 bit using the technique of privacy amplification.

Both of Fig. 5 and Fig. 6 show key expansion results for different batch sizes of sifted bit strings ranging from 5000 to 50000 bits. Fig. 5 represents typical results obtained from QSSL Mode-2 sessions, whereby Taylor's authentication tags of 31-bit size has been used to protect public channel exchanges. The authentication cost curve in this figure represents the amount of PSK bits required for the continuous unconditionally-secure authentication of all relevant public channel discussions. The curve of net key expansion gain has been produced by subtracting the amount of authentication cost from the corresponding value of the generated key size. It is obvious that despite of its name, QKD is really a technique for key expansion (or key growing) rather than key distribution.

Fig. 6 shows typical results for the corresponding QSSL Mode-1 sessions. In this latter case, a traditional SSL/TLS message authentication technique (using SHA-1 algorithm) has been used to implement the authentication of QKD public channel discussion. Thus, the authentication cost of this mode is null. Hence, the amount of key expansion for Mode-1 sessions is greater than that obtained from the corresponding Mode-2 sessions. However, keys produced by Mode-1 sessions do not have the property of unconditional security as these resultant from Mode-2 sessions.

Finally, it is important to notice that the cost of unconditionally-secure authentication of public channel messages can be considerably less than that shown in Fig. 5. This is when the so-called "counter-based" authentication is used. However, this is beyond the scope of this paper. A detailed discussion of this issue can be found in [27]. In all cases, it is better to use larger batch sizes of sifted bits in order to obtain a better key expansion gain.

6 CONCLUSION

It is well justified and prudent now to obtain unconditionally-secure services based on combining QKD with OTP and/or unconditionally-secure authentication codes. However, investigating the full flavor of such services requires multi-disciplinary research efforts. We believe that proposing QSSL is a useful step towards a better understanding of the requirements of integrating QC into the already existent and well-tested information security infrastructure. Inspired by QSSL, our next goal is to present an extension of IPSec for QC. This could lead us to deeper insights on the issue of integrating QC protocols within different layers of the Internet protocol stack.

Figure 5: Net Key Expansion Gain for QSSL Mode-2 Sessions.

Figure 6: Net Key Expansion Gain for QSSL Mode-1 Sessions.



7 REFERENCES

[1] P. Zoller, Ed.: Quantum information processing and communication, Strategic report on the current status, visions, and goals for research in Europe, QIST ERA-Pilot Project, Version 1.1 (2005).

[2] R. Hughes, Ed.: A quantum information science and technology roadmap; Part 2: Quantum cryptography, Report of the quantum cryptography technology expert panel, ARDA, LA-UR-04-4085, Version 1.0, (2004).

[3] C. Elliott: Building the quantum network, New Journal of Physics, Vol. 4, pp. 46.1-46.12 (2002).

[4] C. Elliott, D. Pearson, and G. Troxel: Quantum cryptography in practice, ACM SIGCOMM'03 Conference, Germany, pp. 227-238 (2003).

[5] C. Elliott: The DARPA quantum network, BBN Technologies, arXiv: quant-ph/0412029 (2004).

[6] C. Elliott et al: Current status of the DARPA quantum network, BBN Technologies, arXiv: quant-ph/0503058 (2005).

[7] R. Alleaume, Ed.: SECOQC white paper on quantum key distribution and cryptography, Secoqc-WP-v5, Version 5.1 (2007).

[8] M. Dianati and R. Alleaume: Architecture of the Secoqc quantum key distribution network, GET-ENST, France, arXiv: quant-ph/0610202v2 (2006).

[9] M. Sfaxi, S. Ghernaouti-Helie, and G. Ribordy: Using quantum key distribution within IPSec to secure MAN communications, Proceedings of the IFIP-MAN 2005 Conference on Metropolitan Area Networks, Vietnam (2005).

[10] T. Nguyen, M. Sfaxi, and S. Ghernaouti-Helie: 802.11i encryption key distribution using quantum cryptography, Journal of Networks, Vol. 1, No. 5, pp. 9-20 (2006).

[11] A. Pasquinucci: Authentication and routing in simple quantum key distribution networks, UCCI.IT, Italy, arXiv: cs.NI/0506003v1 (2005).

[12] H. Bechman- Pasquinucci and A. Pasquinucci: Quantum key distribution with trusted quantum relay, arXiv: quant-ph/0505089v1 (2005).

[13] C. Williams et al: A high speed quantum communication testbed, NIST Proceedings (2002).

[14] R. Canetti: Universally composable security: A new paradigm for cryptography protocols, Proceeding of FOCS'01, pp. 136-145 (2001).

[15] V. Fernandez et al: Passive optical network approach to gigahertz-clocked multiuser quantum key distribution, IEEE Journal of Quantum Electronics, Vol. 43, No. 2, (2007) (pre-press version, arXiv: quant-ph/0612130).

[16] D. Collins, N. Gisin, and H. de Riedmatten: Quantum relays for long distance quantum cryptography, arXiv: quant-ph/0311101 (2003).

[17] W. Stallings: Cryptography and Network Security, 3rd Edition, Pearson Education International, USA (2003).

[18] T. Dierks and C. Allen: The TLS protocol version 1.0, RFC 2246 (1999).

[19] T. Dierks and E. Rescorla: The TLS protocol version 1.1," RFC 4346 (2006).

[20] P. Eronen and H. Tschofeing, Eds.: Pre-shared key ciphersuites for TLS, RFC 4279 (2005).

[21] U. Blumenthal and P. Goel: Pre-shared key ciphersuites with NULL encryption for TLS, RFC 4785 (2007).

[22] N. Ferguson and B. Schneier: A cryptographic evaluation of IPSec, Counterpane Internet Security Inc. (1999). Available at: www.schneier.com

[23] C. Bennett and G. Brassard: Quantum cryptography: Public key distribution and coin tossing, International Conference on Computers, Systems & Signal Processing, India, pp. 175-179 (1984).

[24] M. Wegman and J. Carter: New hash functions and their use in authentication and set equality, J. Computer and System Sciences, Vol. 22, pp. 256-279 (1981).

[25] R. Taylor: Near optimal unconditionally secure authentication, EUROCRYPT’94, LNCS, Springer-Verlag, Vol. 950, pp.244-253 (1995).

[26] S. Faraj et al: Optical network models for quantum cryptography, Proceedings of 17th IFIP/Sec2002 Conference, Egypt (2002).

[27] S. Faraj: Unconditionally secure authentication in quantum key distribution, i-Manager's Journal on Software Engineering, Vol. 1, No. 3, pp. 30-42 (2007).



Date post:	17-Nov-2023
Category:	Documents
Upload:	uoanbar
View:	0 times
Download:	0 times

Integrating Quantum Cryptography into SSL

Documents