Integrating Quantum Cryptography Into SSL_335

8/7/2019 Integrating Quantum Cryptography Into SSL_335

http://slidepdf.com/reader/full/integrating-quantum-cryptography-into-ssl335 1/11

INTEGRATING QUANTUM CRYPTOGRAPHY INTO SSL

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

Email: [email protected]

ABSTRACTIt 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, aconcentration has been made on the creation of a simple, efficient, general, andflexible architecture that enables the deployment of practical quantum cryptographic-

based security applications. Indeed, QSSL efficiently supports unconditionallysecure encryption (one-time pad) and/or unconditionally secure authentication (basedon universal hashing). A simplified version of QSSL based on BB84 (Bennett-Brassard 84) quantum key distribution (QKD) protocol has been implemented andexperimentally tested. This has enabled us to experimentally assess our protocol

design based on software simulation of the quantum channel events used for QKD.

Keywords: Quantum Cryptography, SSL/TLS, Unconditional security.

1 INTRODUCTION

Quantum information technology can supportentirely new modes of information processing

based on quantum principles. Indeed, there aremany useful tasks in the field, such as quantumcryptography (QC), which involve only a fewconsecutive quantum computational steps. In such

cases, the unwelcome effects of decoherence can beadequately diminished by improving technologyand communication protocols.

Security with today's cryptography can usually be achieved on the basis of computationalcomplexity. Thus, almost all cryptosystems can be

broken with enormous amounts of calculations. Incontrast, QC delivers cryptographic keys whosesecrecy is guaranteed by the laws of physics. QCoffers new methods of secure communications thatare not threatened even by the power of quantumcomputers. Quantum key distribution (QKD) isalready making its first steps outside labs both for

fiber optic networks and also for satellite-based

communications. It is expected that within adecade, it will be possible to place sources of entangled photons on satellites. This would allowglobal 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 quantumcomputations.

2- Increasing complex future requirements for secure network communications to supportdynamically reconfigurable groups of userswith multi-level security.

3- Projections for the ever growing bandwidthdemands for secure communications.

It is well believed now that QC has the potential

to counter these threats and help to meet these

Special Issue of Ubiquitous Computing Security Systems

UbiCC Journal - Volume 5 www.ubicc.org 1 778



future requirements, if it can reach a stage of asufficient maturity. Hence, in order to facilitate theevolution of QC towards a practical "quantuminformation security era" in which QC becomesmore closely integrated with conventionalinformation security systems and communication

networks infrastructures, a more collaboratedscientific research among specialists from severalfields is required. In particular, this researchactivity has to bring together theoretical andexperimental physicists, computer scientists andelectrical engineers, and communications andinformation security specialists.

Throughout this paper, a focus is maintained onthe 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, inaddition to stand-alone point-to-point (PTP)systems, QKD can be integrated within opticalcommunication networks at the physical layer, andwith key-management infrastructures. However,there are several issues to be explored by researchin this direction. Among these issues are [2]:

1- Investigation of network support concerns beyond PTP connectivity.

2- Integration of QKD with conventionalcryptographic and secure communications

infrastructures.3- Exploration of system-level security

attributes of QKD.

The work presented in this paper addresses allof the above issues. It proposes a novel extension of SSL/TLS (Secure Socket Layer/Transport Layer Security) that we call QSSL (Quantum SSL). QSSLallows the integration of QKD capabilities withinthe Internet (or intranet) security architecture. Thissignificantly facilitates applications in theenvironments of "QKD networks".

Some aspects of QKD networks have been

recently addressed in the literature. The "world'sfirst" QKD network that is composed of trustedrelays and/or untrusted photonic switches had beencontinuously running since June 2004 under thesponsorship of the US DARPA [3], [4], [5], [6].This network uses a modification of IPSec tointegrate it with QKD.

In Europe, the SECOQC project has recentlydemonstrated information-theoretically secureQKD over a fiber-based MAN in 2008. In this

project, a dedicated key distribution network infrastructure has been adopted. It is the so-called"network of secrets" [7], [8].

In [9], a performance analysis for a proposalthat integrates QKD into IPSec was presented.Also, a scheme integrating QC in 802.11i securitymechanisms for the distribution of encryption keyswas outlined in [10]. Some issues of authenticationand routing in simple QKD networks were

addressed in [11], [12].Despite that the use of SSL/TLS as theconsumer of random secret bits obtained from QKDhas been already suggested in [4] and [13], theauthor 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 firstexplicitly proposed design and implementation of SSL/TLS extensions for use in various QKDnetworks.

2 QKD NETWORKS

In securing a PTP link, QKD can be used toachieve unconditional security over that link. In thiscase, keys established by QKD are used for one-time pad (OTP) encryption and for information-theoretically secure authentication (based onuniversal hashing). This unconditional security over the PTP link can be proven because of the fact thatthe security of QKD can be expressed in theframework of universal composability [7], [14].This definitely is one of the most importantapplications of QKD.

Alternatively, it is possible to compose

keys obtained from QKD with a classicalcomputationally secure encryption scheme (such asAES). In this case, it would be possible to encryptlarge rates of classical data over the PTP link.However, the final security of the data exchangedover such a link cannot be stronger than the securityof the encryption scheme. Nevertheless, it is still

possible to show that QKD has importantadvantages over other key distribution techniques interms of key security and key renewal rate [2], [7].

In spite of these advantages obtained fromapplying QKD over PTP links, such an applicationalso has important weaknesses. These include

vulnerability to denial of service attacks,vulnerability to traffic analysis, distance- andlocation-dependence, and the insufficient keydelivery in certain situations [3]. The recent work in

building practical QKD networks is aiming tostrengthen the performance of QKD in theseweaker areas. Also, its goal is to overcome alllimitations inherited by PTP links and to obtain thefull advantages of networking environments.

It is possible to define a QKD network asan infrastructure composed of quantum linksconnecting multiple distant nodes that have thecapability of performing QKD. Regarding thehardware of QKD networks, it is convenient to


UbiCC Journal - Volume 5 www.ubicc.org 1779



characterize different QKD network models by thefunctionality that is implemented within the nodes.Thus, beyond stand-alone QKD PTP links, it is

possible from this perspective to differentiate threemain categories of QKD networks [3], [7]:

a) Optically switched QKD networks: In thiscategory, some classical optical functions like beamsplitting, switching, multiplexing, etc., can beapplied at the network nodes on the quantumsignals sent over quantum channels. These opticalfunctions can be used to achieve multi-user QKD.One-to-many connectivity between QKD deviceshas already been demonstrated at gigahertz clock-rate over passive optical access networks [15].Active optical switching can also be used to enableselective connection of any QKD nodes, as inDARPA network [6]. One important advantage of this category is that the corresponding nodes (which

perform classical optical functions) need not to betrusted. However, due to the extra mount of opticallosses introduced, this network model cannot beused to increase the distance of QKD.

b) Trusted relays QKD networks: In this category,local keys are generated over QKD links and thenstored in nodes that are placed on both ends of eachlink. Global key distribution is performed over aQKD path, i.e. a one-dimensional chain of trustedrelays connected by QKD links, establishing aconnection between two end nodes. Hence, secretkeys are forwarded in a hop-by-hop fashion along

the QKD path. This concept of classical trustedrelays can be used to significantly increase thedistance of QKD, provided that the intermediatenodes can be trusted. Thus, this network model has

been exploited by the DARPA QKD network andalso adopted by the SECOQC network.

c) "Full" quantum networks: These are networksthat aim to extend the distance of QKD by using"quantum repeaters", which can be used to aneffective perfect quantum channel by overcoming

propagation losses. In this scheme, it is notnecessary to trust the intermediate network nodes.

However, quantum repeaters cannot be realizedwith current technologies. In addition, it was shownin [16] that another form of quantum nodes called"quantum relays" can be used to extend the distanceof QKD. Quantum relays are simpler to implementthan quantum repeaters; however, they remaintechnologically difficult to build.

As far as the QKD network software isconcerned, we can notice that there are two mainstrategies that are globally considered in building

practical QKD networks. It is possible todifferentiate between them on the basis of thedegree of dependence of the developed QKD

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

A. Tightly-coupled protocol stack strategy: In thisstrategy, secret random bits obtained from QKD(which is mainly a physical layer technology) aremerged directly somehow into a conventionalhigher-layer security protocol suite. Thus, theconsumer security protocol has to be modified toenable the integration of QKD within it. The work of DARPA QKD network is a good representativeof such an approach where IPSec is used as theconsumer protocol. Indeed, the work presented inthis paper can also be considered under thiscategory with SSL/TLS being used as the consumer higher-layer protocol. The advantage of this

strategy is that it greatly facilitates directimplementation of QKD on private intranets (withan open possibility of a practical Internetimplementation at some later mid-term stage). Thisis mainly because that we make use of alreadyexisting capabilities of networking and security

protocols with some modifications.

B. Loosely-coupled protocol stack strategy: Thefocus here is to develop original multi-layer

protocol infrastructures that are dedicated to QKDnetworks. In such a case, the QKD network infrastructure can be viewed as a "new

cryptographic primitive" that is completelyindependent of the way by which random secret bitsobtained from QKD would be used. This is theapproach adopted by the SECOQC project. Of course, this approach may get the more of network environments by developing original routing andnetwork management techniques. Hence, thisstrategy can be considered as a rather longer-termversion of QKD networks.

3 SSL/TLS OVERVIEW

SSL was originally developed by Netscape.

SSLv3 was designed with public review and inputfrom industry [17]. Then, the TLS working groupwas formed within IETF (Internet Engineering Task Force) and published TLSv1.0 [18] that is veryclose to SSLv3 and can be viewed as SSLv3.1.Later, TLSv1.1 [19], which is a minor modificationof TLSv1.0, had been proposed.

The "socket layer" lives between the applicationlayer and the transport layer in the TCP/IP protocolstack. SSL/TLS (or just simply SSL) contains twolayers of protocols. The SSL Record Protocol

provides basic security services to various higher-layer protocols and defines the format used totransmit data. Also, SSL defines three higher-layer





protocols that use the SSL Record Protocol. Thesethree protocols are used in the management of SSLexchanges. The first is the Change Cipher SpecProtocol, which updates the cipher suite (list of acombination of cryptographic algorithms) to beused on SSL connection. The second is the Alert

Protocol that is used to convey SSL-related alerts tothe 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 transientand each connection is associated with one SSLsession. An SSL session is an association that iscreated by the Handshake Protocol. The sessiondefines a set of cryptographic security parametersthat can be shared among multiple connections.Thus, it is possible to avoid the expensive

negotiation of new security parameters. Once asession is established, there is a "current" operatingstate for both read and write (i.e. receive and send)."Pending" read and write states are created duringthe handshaking. Then, upon a successfullycompleted handshaking, pending states become thecurrent states.

The SSL Record Protocol provides the servicesof confidentiality and data integrity for SSLconnections. On transmission, the SSL RecordProtocol takes an application message, fragments itinto manageable blocks, optionally compresses thedata, applies a MAC (message authentication code),

encrypts, adds a header, and finally transmits theresulting unit in TCP segments. On reception,received data are decrypted, verified,decompressed, reassembled, and then delivered tohigher-level users.

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

The Handshake Protocol allows the twocommunicating parties (client and server) toauthenticate each other. It also enables them to

negotiate an encryption algorithm, a MAC, andcryptographic keys required to protect data sent inSSL. The Handshake Protocol consists of a seriesof messages exchanged by client and server, asshown in Fig. 1. This exchange can be viewed ashaving four phases [17]:

Phase 1- Establish security capabilities:This phase is used to initiate a logical

connection and to establish the associated securitycapabilities. It starts by a client-hello message andends with a server- hello message. During this

phase, the client and server negotiate the SSLversion to be used, session ID, compression

method, and the cipher suite. They also exchangerandom structures to serve as nonces. A cipher suitedefines a key exchange algorithm and aCipherSpec, which includes encryption algorithm,MAC algorithm, and some other relatedinformation. 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). Thiscertificate message is required for any agreed-onkey exchange except anonymous DH. Next, aserver-key-exchange message can be sent (if required). This message is not needed if an RSAkey exchange is used or if the server has sent acertificate with fixed DH parameters. Then, anonanonymous server can request a certificate from

the client by sending the certificate-requestmessage. 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 messagewhose purpose is to enable the client and the server to create a pre-master-secret. The content of thismessage depends on the key exchange method. Theexchanged 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 eachsession. Then, CipherSpec parameters are generatedfrom the master-secret using a certain hashingtechnique. These parameters are a client write MACsecret, a server write MAC secret, a client writekey, a server write key, a client write IV(initialization vector), and a server write IV.Finally, the client may send a certificate-verifymessage to provide explicit verification of itscertificate.

Phase 4- Finish:The client sends a change-cipher-spec message

and copies the pending (CipherSpec) states into thecurrent states (Note that this message is sent usingthe Change Cipher Spec Protocol). Then, it sendsthe finished message under the new algorithms,keys, and secrets. Finally, the server sends itschange-cipher-spec, transfers the pending to thecurrent CipherSpec, and sends its finished message.





Figure 1: Handshake Protocol MessageExchange.

If an SSL session exists, then the twocommunicating parties share a symmetric secret-key that can be used to establish new SSLconnections, thereby avoiding expensive public-keyoperations 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 aresymmetric keys, shared in advance among thecommunicating parties. The first set of these cipher suites uses only symmetric-key operations for authentication. The second set uses DH exchangeauthenticated 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-onlymode, where they can offer authentication andintegrity protection with no confidentiality [20],[21].

4 THE QSSL PROTOCOL

In this section, the Quantum SSL (QSSL) protocol is described. This is mainly done bydescribing the most important modifications and

extensions introduced to the "conventional"

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

1- The choice of SSL/TLS: SSL has been chosenas the basic protocol for this work because it isa very widely used, relatively simple, and well-designed security protocol. In a comparison,

IPSec has been always considered to be overlycomplex protocol that includes somesignificant flaws (see for example [22]).However, each of SSL and IPSec has its ownrelative advantages and disadvantages, whichmainly come from their different functioninglocations in the network protocol stack.

2- Simplicity and efficiency: During thedevelopment of QSSL, we have tried tointroduce the minimum possible modificationsand extensions to SSL that result in an efficientintegration of QC within SSL. This approachalso has enabled the avoidance of designing a

completely new protocol, which may containan expected security flaws. Indeed, thisintegration ha efficiently facilitated both of SSL and QC to get benefits from each other.On one hand, SSL can obtain fresh secret keysfrom QKD. On the other hand, the requiredclassical public discussions of QC can beconveyed using SSL encapsulation.

3- Generality: QSSL is not directed towards aspecific QKD protocol implementation. Wehave tried to make the extensions as general as

possible such that different QKDimplementations and phase components can be

considered. Indeed, other QC protocols rather than QKD might also be considered in thefuture.

4- Traditional vs. unconditionally secureencryption: Each of the unconditionally secureencryption using OTP and traditionalencryption (such as 3DES, AES, etc.) has itsown advantages and requirements. Hence,QSSL supports both types of encryption (Notethat "conventional" SSL/TLS does not supportOTP).

5- Message authentication: Traditionally usedMACs can only offer computationally-secure

data integrity. But authentication codes basedon universal hashing may offer unconditionally-secure data integrity.However, these authentication codes needsecret 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. Thisintroduction of the service of unconditionally-secure data integrity for the application trafficmight be one of the important novel aspects of QSSL. Note; however, that this feature is apartfrom the mandatory use of unconditionally-









handshake messages and for resuming QSSLsessions (when it is allowed). QSSL sessions can beresumed if and only if both of encryption andmessage digest algorithms used for applicationtraffic are not unconditionally-secure. Otherwise,connections cannot be generated from sessions

because this can be fatal for the specified propertyof unconditional security.The pre-master-secret-2 is to be used as a PSK

for initiating future QSSL sessions. Hence, its sizehas to be negotiated by users during handshakingsuch that its size is adequate to enable the use of unconditionally-secure authentication for protectingthe QKD public channel. Note that this separationof the pre-master-secret into two independent partsis necessary from the respective of unconditionalsecurity.

4.4 QSSL Mode-1

This mode represents QSSL handshaking basedon using public-key cryptography for initialization.Any of the traditional SSL/TLS key exchangetechniques (except for the anonymous DH) can beused. The sequence of message exchange of QSSLMode-1 is very similar to that of SSL/TLSdescribed previously in Section 3. However, thereare some required modifications to be noted. Themost important of these are:

1- At least three new parameters should be addedfor negotiation in the client-hello and server-hello messages. These parameters are the sizeof write MAC secrets, the size of write keys,

and the size of the pre-master-secret. The firstof these is to be added whenever unconditionally-secure authentication isrequired for QSSL application traffic. Thesecond parameter is included when it isintended to use OTP encryption. Finally, thethird parameter is added whenever users havethe intention to generate PSKs for futureMode-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 befinished before exchanging any change-cipher-spec message. Hence, the whole QKD messageexchange is inserted between Phase 3 andPhase 4 of SSL Handshake described

previously.3- QKD continues until the complete generation

of the negotiated key sizes. After this pointonly, change-cipher-spec and finishedmessages (Phase 4) can be exchanged (Thisissue also applies to QSSL Mode-2).

4.5 QSSL Mode-2This handshaking mode uses PSK based

initialization. This offers a very high speed sessioninitialization compared with the relatively slow

public-key cryptography based Mode-1initialization. Fig. 3 shows the basic Mode-2

message exchange. QKD message exchange is alsois completely inserted just before the transmissionof change-cipher-spec and finished messages.

Besides the three security parameters added tothe negotiation by the client-hello and server-hellomessages mentioned previously, there is animportant modification to server-key-exchange andclient-key-exchange messages in this mode. InQSSL Mode-2, these two messages are used for identification and synchronization of PSK pads. Atfirst, the server-key-exchange message is used tocarry 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 mayalso 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, whenreceived, is to be interpreted as a positiveacknowledgement of the "PSK identity hint".Otherwise, an unknown-psk-identity alert messagehas to be sent by the client.

4.6 Key pads managementBasically, 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 thewrite keys and write MAC secrets are used directlyafter their generation for protecting application datatraffic. In this case, only PSK pads (whengenerated) need somewhat a loner-termmanagement.

However, it is also possible to use QSSL in akey-store operation mode, wherein all keys aregenerated in much larger sizes and stored for futureusage. This requires the development of management and synchronization mechanisms for five key pads per user (one pad for each of the fivekeys generated from QKD). This number would be

duplicated considering any additional securityrelation with a new user. At this stage of QSSL, we

believe it is not a good practice to include suchmechanisms within QSSL. It might be better todevelop such mechanisms out-of-band. However,this issue could be re-considered in a future QSSLversion.







The experimental setup consists of two QSSLinstances installed onto two PCs (each with 1.7GHz Intel Pentium IV processor). These two PCsare connected via an Ethernet. Sample resultsshowing the amount of net key expansion gain for different QSSL sessions are illustrated in Figure 5

and Figure 6. In these two figures, all QKDsessions have been performed at a quantum bit error rate (QBER) of 5%. Also, 20% of sifted bits have

been used for public comparison to estimate theamount of QBER. This estimation is required to setthe parameters of the reconciliation phase and todecide whether to proceed with the QKD protocolor not. Eve's information about the cryptographickeys generated from all QKD sessions has beenreduced well below 10 -70 bit using the technique of

privacy amplification.Both of Fig. 5 and Fig. 6 show key expansion

results for different batch sizes of sifted bit strings

ranging from 5000 to 50000 bits. Fig. 5 representstypical results obtained from QSSL Mode-2sessions, whereby Taylor's authentication tags of 31-bit size has been used to protect public channelexchanges. The authentication cost curve in thisfigure represents the amount of PSK bits requiredfor the continuous unconditionally-secureauthentication of all relevant public channeldiscussions. The curve of net key expansion gainhas 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 keydistribution.

Fig. 6 shows typical results for thecorresponding QSSL Mode-1 sessions. In this latter case, a traditional SSL/TLS message authenticationtechnique (using SHA-1 algorithm) has been usedto implement the authentication of QKD publicchannel discussion. Thus, the authentication cost of this mode is null. Hence, the amount of keyexpansion for Mode-1 sessions is greater than thatobtained from the corresponding Mode-2 sessions.However, keys produced by Mode-1 sessions donot 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 publicchannel messages can be considerably less than thatshown in Fig. 5. This is when the so-called"counter-based" authentication is used. However,this is beyond the scope of this paper. A detaileddiscussion of this issue can be found in [27]. In allcases, it is better to use larger batch sizes of sifted

bits in order to obtain a better key expansion gain.

6 CONCLUSION

It is well justified and prudent now to obtainunconditionally-secure services based oncombining QKD with OTP and/or unconditionally-secure authentication codes. However, investigating

the full flavor of such services requires multi-disciplinary research efforts. We believe that proposing QSSL is a useful step towards a better understanding of the requirements of integratingQC into the already existent and well-testedinformation security infrastructure. Inspired byQSSL, our next goal is to present an extension of IPSec for QC. This could lead us to deeper insightson the issue of integrating QC protocols withindifferent layers of the Internet protocol stack.

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

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





7 REFERENCES

[1] P. Zoller, Ed.: Quantum information processing and communication, Strategicreport 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 thequantum 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 onquantum 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 distributionwithin IPSec to secure MANcommunications, 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 distributionusing 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 withtrusted quantum relay, arXiv: quant-

ph/0505089v1 (2005).

[13] C. Williams et al: A high speed quantumcommunication 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 quantumcryptography, arXiv: quant-ph/0311101 (2003).

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

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

[19] T. Dierks and E. Rescorla: The TLS protocolversion 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 keyciphersuites 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 andcoin tossing, International Conference onComputers, Systems & Signal Processing ,India, pp. 175-179 (1984).

[24] M. Wegman and J. Carter: New hashfunctions and their use in authentication andset equality, J. Computer and SystemSciences , Vol. 22, pp. 256-279 (1981).

[25] R. Taylor: Near optimal unconditionallysecure 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 17 th IFIP/Sec2002 Conference , Egypt (2002).

[27] S. Faraj: Unconditionally secureauthentication in quantum key distribution, i-

Manager's Journal on Software Engineering ,Vol. 1, No. 3, pp. 30-42 (2007).



Documents

Integrating Quantum Cryptography Into SSL_335