Special Issue of Ubiquitous Computing Security Systems

INTEGRATING QUANTUM CRYPTOGRAPHY INTO SSL

Sufyan T. Faraj
M IEEE, Associate Prof., College of Computers, University of Anbar, Iraq
Email: sufyantaih@yahoo.com

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 communications. It is expected that within a

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
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

UbiCC Journal - Volume 5 www.ubicc.org 1778

Special Issue of Ubiquitous Computing Security Systems
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].
UbiCC Journal - Volume 5 www.ubicc.org
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
1779
Special Issue of Ubiquitous Computing Security Systems
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
UbiCC Journal - Volume 5 www.ubicc.org
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
1780
Special Issue of Ubiquitous Computing Security Systems
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
UbiCC Journal - Volume 5 www.ubicc.org
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.
1781
Special Issue of Ubiquitous Computing Security Systems
SSL/TLS. In the beginning, some important design
issues of QSSL are presented as follows:
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"
UbiCC Journal - Volume 5 www.ubicc.org
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-
1782
Special Issue of Ubiquitous Computing Security Systems
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
UbiCC Journal - Volume 5 www.ubicc.org
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.
1783
Special Issue of Ubiquitous Computing Security Systems
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
UbiCC Journal - Volume 5 www.ubicc.org
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
1784
Special Issue of Ubiquitous Computing Security Systems
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).
UbiCC Journal - Volume 5 www.ubicc.org
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.
1785
Special Issue of Ubiquitous Computing Security Systems
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.
UbiCC Journal - Volume 5 www.ubicc.org
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.
1786
Special Issue of Ubiquitous Computing Security Systems

The experimental setup consists of two QSSL 6 CONCLUSION

instances installed onto two PCs (each with 1.7
GHz Intel Pentium IV processor). These two PCs It is well justified and prudent now to obtain
are connected via an Ethernet. Sample results unconditionally-secure services based on
showing the amount of net key expansion gain for combining QKD with OTP and/or unconditionally-
different QSSL sessions are illustrated in Figure 5 secure authentication codes. However, investigating
and Figure 6. In these two figures, all QKD the full flavor of such services requires multi-
sessions have been performed at a quantum bit error disciplinary research efforts. We believe that
rate (QBER) of 5%. Also, 20% of sifted bits have proposing QSSL is a useful step towards a better
been used for public comparison to estimate the understanding of the requirements of integrating
amount of QBER. This estimation is required to set QC into the already existent and well-tested
the parameters of the reconciliation phase and to information security infrastructure. Inspired by
decide whether to proceed with the QKD protocol QSSL, our next goal is to present an extension of
or not. Eve's information about the cryptographic IPSec for QC. This could lead us to deeper insights
keys generated from all QKD sessions has been on the issue of integrating QC protocols within
reduced well below 10-70 bit using the technique of different layers of the Internet protocol stack.
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 Figure 5: Net Key Expansion Gain for QSSL
case, a traditional SSL/TLS message authentication Mode-2 Sessions.
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.
Figure 6: Net Key Expansion Gain for QSSL
Mode-1 Sessions.

UbiCC Journal - Volume 5 www.ubicc.org 1787

Special Issue of Ubiquitous Computing Security Systems
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).
UbiCC Journal - Volume 5 www.ubicc.org
[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).
1788