Integrating Quantum Cryptography into SSL 335

Document Sample
Integrating Quantum Cryptography into SSL 335 Powered By Docstoc
					Special Issue of Ubiquitous Computing Security Systems


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

             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
                                                             decade, it will be possible to place sources of
    Quantum information technology can support               entangled photons on satellites. This would allow
entirely new modes of information processing                 global quantum communication, teleportation, and
based on quantum principles. Indeed, there are               perfectly secure cryptography [1].
many useful tasks in the field, such as quantum                  While conventional methods continue to meet
cryptography (QC), which involve only a few                  the more-demanding information security needs of
consecutive quantum computational steps. In such             our increasingly networked world, the face
cases, the unwelcome effects of decoherence can be           increasing technological challenges, such as [2]:
adequately diminished by improving technology                     1- Unanticipated advances in mathematics,
and communication protocols.                                         high-performance computing, and the
    Security with today's cryptography can usually                   possibility    of    large-scale   quantum
be achieved on the basis of computational                            computations.
complexity. Thus, almost all cryptosystems can be                 2- Increasing complex future requirements for
broken with enormous amounts of calculations. In                     secure network communications to support
contrast, QC delivers cryptographic keys whose                       dynamically reconfigurable groups of users
secrecy is guaranteed by the laws of physics. QC                     with multi-level security.
offers new methods of secure communications that                  3- Projections for the ever growing bandwidth
are not threatened even by the power of quantum                      demands for secure communications.
computers. Quantum key distribution (QKD) is
already making its first steps outside labs both for            It is well believed now that QC has the potential
fiber optic networks and also for satellite-based            to counter these threats and help to meet these

UbiCC Journal - Volume 5                                                                1778
Special Issue of Ubiquitous Computing Security Systems

future requirements, if it can reach a stage of a               In [9], a performance analysis for a proposal
sufficient maturity. Hence, in order to facilitate the      that integrates QKD into IPSec was presented.
evolution of QC towards a practical "quantum                Also, a scheme integrating QC in 802.11i security
information security era" in which QC becomes               mechanisms for the distribution of encryption keys
more closely integrated with conventional                   was outlined in [10]. Some issues of authentication
information security systems and communication              and routing in simple QKD networks were
networks infrastructures, a more collaborated               addressed in [11], [12].
scientific research among specialists from several              Despite that the use of SSL/TLS as the
fields is required. In particular, this research            consumer of random secret bits obtained from QKD
activity has to bring together theoretical and              has been already suggested in [4] and [13], the
experimental physicists, computer scientists and            author is not aware of any specific proposal or
electrical engineers, and communications and                design explicitly dealing with the extension of
information security specialists.                           SSL/TLS for QKD integration. To the best of
    Throughout this paper, a focus is maintained on         author knowledge, this work represents the first
the subfield of QKD. QKD basically enables two              explicitly proposed design and implementation of
parties (traditionally referred to as Alice and Bob)        SSL/TLS extensions for use in various QKD
to produce the shared secret keys required for              networks.
secure communications, through a combination of
quantum and conventional communication steps.               2 QKD NETWORKS
Today QKD systems can be operated over metro-
area distances on optical fibers, and across multi-             In securing a PTP link, QKD can be used to
kilometer line-of-sight "free-space" paths. Thus, in        achieve unconditional security over that link. In this
addition to stand-alone point-to-point (PTP)                case, keys established by QKD are used for one-
systems, QKD can be integrated within optical               time pad (OTP) encryption and for information-
communication networks at the physical layer, and           theoretically secure authentication (based on
with key-management infrastructures. However,               universal hashing). This unconditional security over
there are several issues to be explored by research         the PTP link can be proven because of the fact that
in this direction. Among these issues are [2]:              the security of QKD can be expressed in the
   1- Investigation of network support concerns             framework of universal composability [7], [14].
        beyond PTP connectivity.                            This definitely is one of the most important
   2- Integration of QKD with conventional                  applications of QKD.
        cryptographic and secure communications                      Alternatively, it is possible to compose
        infrastructures.                                    keys obtained from QKD with a classical
   3- Exploration of system-level security                  computationally secure encryption scheme (such as
        attributes of QKD.                                  AES). In this case, it would be possible to encrypt
                                                            large rates of classical data over the PTP link.
    The work presented in this paper addresses all          However, the final security of the data exchanged
of the above issues. It proposes a novel extension of       over such a link cannot be stronger than the security
SSL/TLS (Secure Socket Layer/Transport Layer                of the encryption scheme. Nevertheless, it is still
Security) that we call QSSL (Quantum SSL). QSSL             possible to show that QKD has important
allows the integration of QKD capabilities within           advantages over other key distribution techniques in
the Internet (or intranet) security architecture. This      terms of key security and key renewal rate [2], [7].
significantly facilitates applications in the                        In spite of these advantages obtained from
environments of "QKD networks".                             applying QKD over PTP links, such an application
    Some aspects of QKD networks have been                  also has important weaknesses. These include
recently addressed in the literature. The "world's          vulnerability to denial of service attacks,
first" QKD network that is composed of trusted              vulnerability to traffic analysis, distance- and
relays and/or untrusted photonic switches had been          location-dependence, and the insufficient key
continuously running since June 2004 under the              delivery in certain situations [3]. The recent work in
sponsorship of the US DARPA [3], [4], [5], [6].             building practical QKD networks is aiming to
This network uses a modification of IPSec to                strengthen the performance of QKD in these
integrate it with QKD.                                      weaker areas. Also, its goal is to overcome all
    In Europe, the SECOQC project has recently              limitations inherited by PTP links and to obtain the
demonstrated information-theoretically secure               full advantages of networking environments.
QKD over a fiber-based MAN in 2008. In this                          It is possible to define a QKD network as
project, a dedicated key distribution network               an infrastructure composed of quantum links
infrastructure has been adopted. It is the so-called        connecting multiple distant nodes that have the
"network of secrets" [7], [8].                              capability of performing QKD. Regarding the
                                                            hardware of QKD networks, it is convenient to

UbiCC Journal - Volume 5                                                                1779
Special Issue of Ubiquitous Computing Security Systems

characterize different QKD network models by the           network software on the pre-existing conventional
functionality that is implemented within the nodes.        network security infrastructure. We shall name
Thus, beyond stand-alone QKD PTP links, it is              these two strategies as: tightly-coupled protocol
possible from this perspective to differentiate three      stack strategy and loosely-coupled protocol stack
main categories of QKD networks [3], [7]:                  strategy. They are explained as follows:

a) Optically switched QKD networks: In this                A. Tightly-coupled protocol stack strategy: In this
category, some classical optical functions like beam       strategy, secret random bits obtained from QKD
splitting, switching, multiplexing, etc., can be           (which is mainly a physical layer technology) are
applied at the network nodes on the quantum                merged directly somehow into a conventional
signals sent over quantum channels. These optical          higher-layer security protocol suite. Thus, the
functions can be used to achieve multi-user QKD.           consumer security protocol has to be modified to
One-to-many connectivity between QKD devices               enable the integration of QKD within it. The work
has already been demonstrated at gigahertz clock-          of DARPA QKD network is a good representative
rate over passive optical access networks [15].            of such an approach where IPSec is used as the
Active optical switching can also be used to enable        consumer protocol. Indeed, the work presented in
selective connection of any QKD nodes, as in               this paper can also be considered under this
DARPA network [6]. One important advantage of              category with SSL/TLS being used as the consumer
this category is that the corresponding nodes (which       higher-layer protocol. The advantage of this
perform classical optical functions) need not to be        strategy is that it greatly facilitates direct
trusted. However, due to the extra mount of optical        implementation of QKD on private intranets (with
losses introduced, this network model cannot be            an open possibility of a practical Internet
used to increase the distance of QKD.                      implementation at some later mid-term stage). This
                                                           is mainly because that we make use of already
b) Trusted relays QKD networks: In this category,          existing capabilities of networking and security
local keys are generated over QKD links and then           protocols with some modifications.
stored in nodes that are placed on both ends of each
link. Global key distribution is performed over a          B. Loosely-coupled protocol stack strategy: The
QKD path, i.e. a one-dimensional chain of trusted          focus here is to develop original multi-layer
relays connected by QKD links, establishing a              protocol infrastructures that are dedicated to QKD
connection between two end nodes. Hence, secret            networks. In such a case, the QKD network
keys are forwarded in a hop-by-hop fashion along           infrastructure can be viewed as a "new
the QKD path. This concept of classical trusted            cryptographic primitive" that is completely
relays can be used to significantly increase the           independent of the way by which random secret bits
distance of QKD, provided that the intermediate            obtained from QKD would be used. This is the
nodes can be trusted. Thus, this network model has         approach adopted by the SECOQC project. Of
been exploited by the DARPA QKD network and                course, this approach may get the more of network
also adopted by the SECOQC network.                        environments by developing original routing and
                                                           network management techniques. Hence, this
c) "Full" quantum networks: These are networks             strategy can be considered as a rather longer-term
that aim to extend the distance of QKD by using            version of QKD networks.
"quantum repeaters", which can be used to an
effective perfect quantum channel by overcoming            3 SSL/TLS OVERVIEW
propagation losses. In this scheme, it is not
necessary to trust the intermediate network nodes.             SSL was originally developed by Netscape.
However, quantum repeaters cannot be realized              SSLv3 was designed with public review and input
with current technologies. In addition, it was shown       from industry [17]. Then, the TLS working group
in [16] that another form of quantum nodes called          was formed within IETF (Internet Engineering Task
"quantum relays" can be used to extend the distance        Force) and published TLSv1.0 [18] that is very
of QKD. Quantum relays are simpler to implement            close to SSLv3 and can be viewed as SSLv3.1.
than quantum repeaters; however, they remain               Later, TLSv1.1 [19], which is a minor modification
technologically difficult to build.                        of TLSv1.0, had been proposed.
                                                               The "socket layer" lives between the application
    As far as the QKD network software is                  layer and the transport layer in the TCP/IP protocol
concerned, we can notice that there are two main           stack. SSL/TLS (or just simply SSL) contains two
strategies that are globally considered in building        layers of protocols. The SSL Record Protocol
practical QKD networks. It is possible to                  provides basic security services to various higher-
differentiate between them on the basis of the             layer protocols and defines the format used to
degree of dependence of the developed QKD                  transmit data. Also, SSL defines three higher-layer

UbiCC Journal - Volume 5                                                           1780
Special Issue of Ubiquitous Computing Security Systems

protocols that use the SSL Record Protocol. These            method, and the cipher suite. They also exchange
three protocols are used in the management of SSL            random structures to serve as nonces. A cipher suite
exchanges. The first is the Change Cipher Spec               defines a key exchange algorithm and a
Protocol, which updates the cipher suite (list of a          CipherSpec, which includes encryption algorithm,
combination of cryptographic algorithms) to be               MAC algorithm, and some other related
used on SSL connection. The second is the Alert              information. The exchange methods supported by
Protocol that is used to convey SSL-related alerts to        SSL/TLS are: RSA, fixed DH (Diffie-Hellman),
the peer entity. The third is the Handshake Protocol,        ephemeral (temporary) DH, and anonymous DH.
which is the most complex part of SSL and it is
briefly described later in this section.                     Phase 2- Server authentication and key exchange:
    An SSL connection is a transport (in the OSI                 In the beginning of this phase, the server sends
layering model definition) that provides a peer-to-          its certificate (if it needs to be authenticated). This
peer type of service. SSL connections are transient          certificate message is required for any agreed-on
and each connection is associated with one SSL               key exchange except anonymous DH. Next, a
session. An SSL session is an association that is            server-key-exchange message can be sent (if
created by the Handshake Protocol. The session               required). This message is not needed if an RSA
defines a set of cryptographic security parameters           key exchange is used or if the server has sent a
that can be shared among multiple connections.               certificate with fixed DH parameters. Then, a
Thus, it is possible to avoid the expensive                  nonanonymous server can request a certificate from
negotiation of new security parameters. Once a               the client by sending the certificate-request
session is established, there is a "current" operating       message. Finally, this phase ends with a server-
state for both read and write (i.e. receive and send).       done message.
"Pending" read and write states are created during
the handshaking. Then, upon a successfully                   Phase 3- Client authentication and key exchange:
completed handshaking, pending states become the                 The client begins this phase by sending a
current states.                                              certificate message (if the server has requested it).
    The SSL Record Protocol provides the services            Next, it sends the client-key-exchange message
of confidentiality and data integrity for SSL                whose purpose is to enable the client and the server
connections. On transmission, the SSL Record                 to create a pre-master-secret. The content of this
Protocol takes an application message, fragments it          message depends on the key exchange method. The
into manageable blocks, optionally compresses the            exchanged pre-master-secret is to be used later by
data, applies a MAC (message authentication code),           both parties to calculate the shared master-secret,
encrypts, adds a header, and finally transmits the           which is a 384-bit value that is generated for each
resulting unit in TCP segments. On reception,                session. Then, CipherSpec parameters are generated
received      data     are     decrypted,     verified,      from the master-secret using a certain hashing
decompressed, reassembled, and then delivered to             technique. These parameters are a client write MAC
higher-level users.                                          secret, a server write MAC secret, a client write
    Four content types are defined by the Record             key, a server write key, a client write IV
Protocol. These are the three SSL-specific protocols         (initialization vector), and a server write IV.
(change-cipher-spec, alert, and handshake) and               Finally, the client may send a certificate-verify
application-data, which corresponds to any                   message to provide explicit verification of its
application that might use SSL.                              certificate.
    The Handshake Protocol allows the two
communicating parties (client and server) to                 Phase 4- Finish:
authenticate each other. It also enables them to                The client sends a change-cipher-spec message
negotiate an encryption algorithm, a MAC, and                and copies the pending (CipherSpec) states into the
cryptographic keys required to protect data sent in          current states (Note that this message is sent using
SSL. The Handshake Protocol consists of a series             the Change Cipher Spec Protocol). Then, it sends
of messages exchanged by client and server, as               the finished message under the new algorithms,
shown in Fig. 1. This exchange can be viewed as              keys, and secrets. Finally, the server sends its
having four phases [17]:                                     change-cipher-spec, transfers the pending to the
                                                             current CipherSpec, and sends its finished message.
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                                                               1781
Special Issue of Ubiquitous Computing Security Systems

                                                          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
       Figure 1: Handshake Protocol Message                     specific QKD protocol implementation. We
                   Exchange.                                    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
    If an SSL session exists, then the two
communicating parties share a symmetric secret-                 than QKD might also be considered in the
key that can be used to establish new SSL                       future.
                                                             4- Traditional     vs.     unconditionally     secure
connections, thereby avoiding expensive public-key
operations required for session establishment.                  encryption: Each of the unconditionally secure
    In two recent RFCs (Request for Comments),                  encryption using OTP and traditional
                                                                encryption (such as 3DES, AES, etc.) has its
three new sets of pre-shared key (PSK) cipher
suites have been defined for TLS. These PSKs are                own advantages and requirements. Hence,
symmetric keys, shared in advance among the                     QSSL supports both types of encryption (Note
                                                                that "conventional" SSL/TLS does not support
communicating parties. The first set of these cipher
suites uses only symmetric-key operations for                   OTP).
authentication. The second set uses DH exchange              5- Message authentication: Traditionally used
                                                                MACs can only offer computationally-secure
authenticated with a PSK. The third set combines
public-key authentication of the server with PSK                data integrity. But authentication codes based
authentication of the client. Indeed, these PSK                 on      universal      hashing      may      offer
cipher suites may be used in an authentication-only             unconditionally-secure        data       integrity.
mode, where they can offer authentication and                   However, these authentication codes need
integrity protection with no confidentiality [20],              secret bits to be initially shared by authorized
[21].                                                           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
   In this section, the Quantum SSL (QSSL)                      might be one of the important novel aspects of
protocol is described. This is mainly done by                   QSSL. Note; however, that this feature is apart
describing the most important modifications and                 from the mandatory use of unconditionally-
extensions introduced to the "conventional"

UbiCC Journal - Volume 5                                                                1782
Special Issue of Ubiquitous Computing Security Systems

     secure authentication codes for protecting             Cryptography Protocol is shown in Fig. 2. Each
     public channel discussions of QKD.                     message of the Quantum Cryptography Protocol
  6- Network         initialization:   To     achieve       has the following fields:
     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                       Figure 2: Message Format of the QSSL
     unconditional security in a strict sense, they                 Quantum Cryptography Protocol.
     still present a security advantage over any other
     conventional key distribution technique, as
     argued in [7]. Thus, both of these QKD                   • Type (2 bytes): Indicates one of the messages
     network initialization modes are supported by              used in the public exchange phase of the QC
     QSSL.                                                      protocol. Some of the messages defined for
  7- Applicability: In a contrast with classical open           QKD are listed in Table 1.
     networks (such as the Internet), QKD networks            • Protocol (1 byte): The QC protocol used (e.g.
     can be considered as "closed" networks,                    the BB84 QKD protocol due to Bennett and
     especially at this early development stage. This           Brassard [23]).
     is mainly due to the physical limitations they           • Version (1 byte): Enables the use of more than
     have. Thus, QSSL is more suitable (at least for            one version of a certain QC protocol. Thus,
     the time being) for application in private                 components of different characteristics can be
     intranets rather than the public Internet.                 used to implement any phase of that protocol.
     However, as such private networks are already              For example, different techniques for sifting,
     used by many organizations; the deployment of              reconciliation, estimating eavesdropper's (Eve)
     QSSL would bring a considerable security                   information, and/or privacy amplification may
     advantage for these intranets.                             be used for implementing the BB84 protocol.
                                                              • Length (4bytes): The length of the message in
    Various aspects of QSSL are described in the                bytes.
following subsections. Note that for a reason of              • Job no. (2 bytes): Enables the operation of
clarity, QSSL handshake is described as two                     multiple QC protocol jobs (or instances), all
modes. Mode-1 is based on the traditional public-               belonging to a one QSSL session.
key initialization of SSL/TLS. Mode-2 is based on             • Authentication (1 byte): Indicates whether this
PSK cipher suites. Otherwise, it is straight forward            message is authenticated. It may also contain
to only describe a single QSSL handshake mode by                some additional information about this
just labeling some messages as situation dependent              authentication (if any).
and specifying the use of suitable cipher suites. The         • Encoding (1 byte): Indicates if a certain
protocol version to be initially used for QSSL is 3.5           encoding technique is used for the content field
(remember that SSLv3 uses 3.0, TLSv1.0 uses 3.1,                of the message. It may also contain some
and TLSv1.1 uses 3.2).                                          additional information about this encoding (if
                                                                any). For example, a form of run-length
4.1 Introducing a new SSL/TLS content type                      encoding is used for the (sparse) messages of
   A fifth content type is introduced for the SSL               the QKD sifting phase.
Record Protocol. This new type is to be called                • Content ( ≥ 0 bytes): The parameters and data
quantum-cryptography and it is related to any QC                associated with this message. Table 1 contains
protocol to be integrated within SSL/TLS. By                    some representative contents of QKD
defining this content type, the QC protocol (e.g.               messages.
QKD) is to be considered as an additional higher-             • Tag: If the message is authenticated, this field
layer SSL/TLS protocol just like the Handshake,                 would contain the corresponding authentication
the Change Cipher Spec, and the Alert protocols.                tag. Its size depends on the used authentication
The message format of the QSSL Quantum                          code.

UbiCC Journal - Volume 5                                                            1783
Special Issue of Ubiquitous Computing Security Systems

                                                               authentication for protecting QKD public channel
                                                               discussions. This is implied by using PSKs for
          Table 1: QKD Protocol Message Types.                 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
4.2 Defining new cipher suites                                 MAC secret, server write MAC secret, client write
    Here, two new sets of cipher suites are defined            key, server write key, client write IV, server write
to be used for QSSL. The first of these sets uses              IV, and pre-master-secret. Note that we have used
public-key cryptography to initialize the QKD                  the same terminology of SSL/TLS. However, the
process. This set is to be applied whenever there is           write MAC secrets are used in the generation of
no possibility for authorized users to initially have          both of traditional and unconditionally-secure
PSKs required for universal hashing. This set may              message digests. Similarly, the write keys are used
also be used when users believe that the security              for both traditional and unconditionally-secure
offered by such cipher suites is adequate for them.            encryption. The write IVs are only generated when
This situation represents what we call QSSL Mode-              traditional block ciphers are used for encrypting
1. The second set of cipher suites uses PSKs to                application traffic. Whenever unconditionally-
facilitate the use of unconditionally-secure                   secure encryption and/or authentication are to be
authentication for protecting the QKD public                   used, the size of the required write keys and/or the
channel. This set can offer provable security and it           size of the required write MAC secrets have to be
corresponds to the second mode of QSSL                         negotiated during QSSL handshake.
handshaking (QSSL Mode-2).
    Table 2 lists some representative examples of                        Table 2: Some QSSL Ciphersuites.
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                      The pre-master-secret generated from QKD is
QSSL because it makes the system vulnerable to                 divided into two parts. The first 48 bytes of it
man-in-the-middle attacks. Furthermore, this set               compose the first part, which we call pre-master-
can only use traditional MACs (such as SHA and                 secret-1. The remaining bits of the pre-master-
MD5) for protecting the QKD public channel. This               secret compose the second part that is to be called
is obviously due to the assumption unavailability of           pre-master-secret-2. Then, the master-secret is
PSKs      required     for     unconditionally-secure          calculated from pre-master-secret-1. The function
authentication. In contrast, the second set of cipher          used for calculating the master-secret in QSSL is
suites    always      use      unconditionally-secure          similar to that used by SSL/TLS. Next, the master-
                                                               secret can be used for authenticating the finished

UbiCC Journal - Volume 5                                                                   1784
Special Issue of Ubiquitous Computing Security Systems

handshake messages and for resuming QSSL                   4.5 QSSL Mode-2
sessions (when it is allowed). QSSL sessions can be            This handshaking mode uses PSK based
resumed if and only if both of encryption and              initialization. This offers a very high speed session
message digest algorithms used for application             initialization compared with the relatively slow
traffic are not unconditionally-secure. Otherwise,         public-key        cryptography     based     Mode-1
connections cannot be generated from sessions              initialization. Fig. 3 shows the basic Mode-2
because this can be fatal for the specified property       message exchange. QKD message exchange is also
of unconditional security.                                 is completely inserted just before the transmission
    The pre-master-secret-2 is to be used as a PSK         of change-cipher-spec and finished messages.
for initiating future QSSL sessions. Hence, its size           Besides the three security parameters added to
has to be negotiated by users during handshaking           the negotiation by the client-hello and server-hello
such that its size is adequate to enable the use of        messages mentioned previously, there is an
unconditionally-secure authentication for protecting       important modification to server-key-exchange and
the QKD public channel. Note that this separation          client-key-exchange messages in this mode. In
of the pre-master-secret into two independent parts        QSSL Mode-2, these two messages are used for
is necessary from the respective of unconditional          identification and synchronization of PSK pads. At
security.                                                  first, the server-key-exchange message is used to
                                                           carry a "PSK identity hint". One possibility for this
4.4 QSSL Mode-1                                            "PSK identity hint" is to be a hash value of some
    This mode represents QSSL handshaking based            bits from the beginning of the PSK pad. This may
on using public-key cryptography for initialization.       also be accompanied by some sort of a sliding-
Any of the traditional SSL/TLS key exchange                window         technique      to    discard     some
techniques (except for the anonymous DH) can be            (unsynchronized) bits from the beginning of pads.
used. The sequence of message exchange of QSSL                 The client-key-exchange message, when
Mode-1 is very similar to that of SSL/TLS                  received, is to be interpreted as a positive
described previously in Section 3. However, there          acknowledgement of the "PSK identity hint".
are some required modifications to be noted. The           Otherwise, an unknown-psk-identity alert message
most important of these are:                               has to be sent by the client.
  1- At least three new parameters should be added
     for negotiation in the client-hello and server-       4.6 Key pads management
     hello messages. These parameters are the size             Basically, QSSL can be considered to be a
     of write MAC secrets, the size of write keys,         protocol that uses QKD to supply users with on-the-
     and the size of the pre-master-secret. The first      fly cryptographic keys. This is accepted a far as the
     of these is to be added whenever                      write keys and write MAC secrets are used directly
     unconditionally-secure     authentication     is      after their generation for protecting application data
     required for QSSL application traffic. The            traffic. In this case, only PSK pads (when
     second parameter is included when it is               generated)     need     somewhat      a    loner-term
     intended to use OTP encryption. Finally, the          management.
     third parameter is added whenever users have              However, it is also possible to use QSSL in a
     the intention to generate PSKs for future             key-store operation mode, wherein all keys are
     Mode-2 initialization (The size of this               generated in much larger sizes and stored for future
     parameter should be ≥ 48 bytes). Note that this       usage. This requires the development of
     point also applies to QSSL Mode-2.                    management and synchronization mechanisms for
  2- QKD (or generally any QC protocol) can only           five key pads per user (one pad for each of the five
     be started after both sides mutually                  keys generated from QKD). This number would be
     authenticate each other. Also, QKD has to be          duplicated considering any additional security
     finished before exchanging any change-cipher-         relation with a new user. At this stage of QSSL, we
     spec message. Hence, the whole QKD message            believe it is not a good practice to include such
     exchange is inserted between Phase 3 and              mechanisms within QSSL. It might be better to
     Phase 4 of SSL Handshake described                    develop such mechanisms out-of-band. However,
     previously.                                           this issue could be re-considered in a future QSSL
  3- QKD continues until the complete generation           version.
     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                                                                1785
Special Issue of Ubiquitous Computing Security Systems

                                                                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
         Figure 3: QSSL Mode-2 Handshake.                 management module. These bits are used by QSSL
                                                          as cryptographic keys in accordance to the specified
                                                          cipher suites.
5 SYSTEM ARCHITECTURE                                         A simplified version of QSSL has been
                                                          implemented based on Microsoft "WinSock"
    The system architecture of a typical QSSL             technology using Visual C/C++ v.6 with system
application is shown in Fig. 4. As the figure             running under Windows XP. This QSSL
indicates, QSSL is located between application            implementation has been integrated with our
layer protocols and TCP. On transmission, QSSL            previously developed BB84 protocol engine [26].
accepts data traffic from the application layer and       This protocol engine is based on software
adds the required security protection before sending      simulation of the BB84 physical layer. It also
it down to lower layers. The BB84 is used as the          includes a suitable code for performing other BB84
QC protocol in this architecture. QSSL uses the           phases. The required unconditionally-secure
network to send two types of traffic. The first is        authentication    for     BB84     public     channel
application data traffic, which is encrypted and          communications has been achieved according to
authenticated according to user's requirement. The        our previously developed authenticated version of
second is the traffic corresponding to the classical      BB84       [27].     This    authenticated      BB84
public     channel     exchanges     required    for      implementation uses Taylor's authentication code
implementing BB84. This latter traffic type is            [25] for obtaining unconditionally secure
transmitted during QSSL handshake and it has to be        authentication tags.
authenticated in order to defeat man-in-the-middle
attack on the QKD protocol.

UbiCC Journal - Volume 5                                                          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
    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                                                              1787
Special Issue of Ubiquitous Computing Security Systems

                                                            [13] C. Williams et al: A high speed quantum
  7 REFERENCES                                                   communication testbed, NIST Proceedings
 [1]  P. Zoller, Ed.: Quantum information                   [14] R. Canetti: Universally composable security:
     processing and communication, Strategic                     A new paradigm for cryptography protocols,
     report on the current status, visions, and                  Proceeding of FOCS'01, pp. 136-145 (2001).
     goals for research in Europe, QIST ERA-                [15] V. Fernandez et al: Passive optical network
     Pilot Project, Version 1.1 (2005).                          approach to gigahertz-clocked multiuser
 [2] R. Hughes, Ed.: A quantum information                       quantum key distribution, IEEE Journal of
     science and technology roadmap; Part 2:                     Quantum Electronics, Vol. 43, No. 2, (2007)
     Quantum cryptography, Report of the                         (pre-press      version,    arXiv:     quant-
     quantum cryptography technology expert                      ph/0612130).
     panel, ARDA, LA-UR-04-4085, Version 1.0,               [16] D. Collins, N. Gisin, and H. de Riedmatten:
     (2004).                                                     Quantum relays for long distance quantum
 [3] C. Elliott: Building the quantum network,                   cryptography, arXiv: quant-ph/0311101
     New Journal of Physics, Vol. 4, pp. 46.1-                   (2003).
     46.12 (2002).                                          [17] W. Stallings: Cryptography and Network
 [4] C. Elliott, D. Pearson, and G. Troxel:                      Security, 3rd Edition, Pearson Education
     Quantum cryptography in practice, ACM                       International, USA (2003).
     SIGCOMM'03 Conference, Germany, pp.                    [18] T. Dierks and C. Allen: The TLS protocol
     227-238 (2003).                                             version 1.0, RFC 2246 (1999).
 [5] C. Elliott: The DARPA quantum network,                 [19] T. Dierks and E. Rescorla: The TLS protocol
     BBN        Technologies,       arXiv:    quant-             version 1.1," RFC 4346 (2006).
     ph/0412029 (2004).                                     [20] P. Eronen and H. Tschofeing, Eds.: Pre-
 [6] C. Elliott et al: Current status of the DARPA               shared key ciphersuites for TLS, RFC 4279
     quantum network, BBN Technologies,                          (2005).
     arXiv: quant-ph/0503058 (2005).                        [21] U. Blumenthal and P. Goel: Pre-shared key
 [7] R. Alleaume, Ed.: SECOQC white paper on                     ciphersuites with NULL encryption for TLS,
     quantum key distribution and cryptography,                  RFC 4785 (2007).
     Secoqc-WP-v5, Version 5.1 (2007).                      [22] N. Ferguson and B. Schneier: A
 [8] M. Dianati and R. Alleaume: Architecture of                 cryptographic      evaluation    of    IPSec,
     the Secoqc quantum key distribution                         Counterpane Internet Security Inc. (1999).
     network, GET-ENST, France, arXiv: quant-                    Available at:
     ph/0610202v2 (2006).                                   [23] C. Bennett and G. Brassard: Quantum
 [9] M. Sfaxi, S. Ghernaouti-Helie, and G.                       cryptography: Public key distribution and
     Ribordy: Using quantum key distribution                     coin tossing, International Conference on
     within       IPSec      to     secure     MAN               Computers, Systems & Signal Processing,
     communications, Proceedings of the IFIP-                    India, pp. 175-179 (1984).
     MAN 2005 Conference on Metropolitan Area               [24] M. Wegman and J. Carter: New hash
     Networks, Vietnam (2005).                                   functions and their use in authentication and
 [10] T. Nguyen, M. Sfaxi, and S. Ghernaouti-                    set equality, J. Computer and System
     Helie: 802.11i encryption key distribution                  Sciences, Vol. 22, pp. 256-279 (1981).
     using quantum cryptography, Journal of                 [25] R. Taylor: Near optimal unconditionally
     Networks, Vol. 1, No. 5, pp. 9-20 (2006).                   secure authentication, EUROCRYPT’94,
 [11] A. Pasquinucci: Authentication and routing                 LNCS, Springer-Verlag, Vol. 950, pp.244-
     in simple quantum key distribution networks,                253 (1995).
     UCCI.IT, Italy, arXiv: cs.NI/0506003v1                 [26] S. Faraj et al: Optical network models for
     (2005).                                                     quantum cryptography, Proceedings of 17th
 [12] H. Bechman- Pasquinucci and A.                             IFIP/Sec2002 Conference, Egypt (2002).
     Pasquinucci: Quantum key distribution with             [27]     S.    Faraj:    Unconditionally    secure
     trusted quantum relay, arXiv: quant-                        authentication in quantum key distribution, i-
     ph/0505089v1 (2005).                                        Manager's Journal on Software Engineering,
                                                                 Vol. 1, No. 3, pp. 30-42 (2007).

UbiCC Journal - Volume 5                                                             1788

Shared By:
Tags: UbiCC, Journal
Description: UBICC, the Ubiquitous Computing and Communication Journal [ISSN 1992-8424], is an international scientific and educational organization dedicated to advancing the arts, sciences, and applications of information technology. With a world-wide membership, UBICC is a leading resource for computing professionals and students working in the various fields of Information Technology, and for interpreting the impact of information technology on society.
UbiCC Journal UbiCC Journal Ubiquitous Computing and Communication Journal
About UBICC, the Ubiquitous Computing and Communication Journal [ISSN 1992-8424], is an international scientific and educational organization dedicated to advancing the arts, sciences, and applications of information technology. With a world-wide membership, UBICC is a leading resource for computing professionals and students working in the various fields of Information Technology, and for interpreting the impact of information technology on society.