KEY MANAGEMENT OF QUANTUM GENERATED KEYS IN IPSEC

Andreas Neppach, Christian Pfaffel-Janser, Ilse Wimberger

Program and System Engineering (PSE), Siemens AG Austria, Gudrunstrasse 11, Vienna, Austria

Thomas Loruenser, Michael Meyenburg

Smart Systems Division, Austrian Research Centers GmbH, Vienna, Austria

Alexander Szekely, Johannes Wolkerstorfer

Institute for Applied Information Processing and Communications, Graz University of Technology, Austria

Keywords:

Quantum cryptography, Key management, Virtual Private Networks (VPN), IPsec, Security gateway, Internet

Key Exchange (IKE).

Abstract:

This paper presents a key management approach for quantum generated keys and its integration into the

IPsec/IKE protocol. The solution is used in a security gateway that integrates quantum key distribution (QKD)

and IPsec as a system-on-chip solution. The QKD acquisition module and the IPsec part of this prototype are

implemented in hardware to provide a high level of integration as well as high encryption throughput. To make

use of these fast encryption capabilities, a ﬂexible key management approach is necessary to provide keys just

in time. Thus, the presented key management approach focuses on an efﬁcient key update mechanism and

minimizes the communication overhead. Furthermore, the presented approach is a ﬁrst step to integrate QKD

solutions into real-world commercial applications using standardized interfaces.

1 INTRODUCTION

Virtual private networks (VPN) are a standard in to-

day’s network infrastructure. Nearly all business ar-

eas use the Internet to exchange data and information.

Many parts of this information are conﬁdential and

thus have to be protected. A VPN provides this func-

tionality and ensures the conﬁdentiality and integrity

of data transferred between two endpoints, even if the

transport medium is insecure.

VPNs typically operate at OSI layer 2 - 4. One

popular protocol is the Internet Protocol security

(IPsec) (Kent, 2005). It operates at layer 3, and pro-

tects all protocols in upper layers (e.g. HTTP, FTP

or SMTP). This simpliﬁes the integration into exist-

ing network infrastructures. Many IPsec implemen-

tations are available for different operating systems

and enable client PCs to perform remote access to e.g.

company intranet or conﬁdential network resources.

In case of e.g. data replication of large databases or

interconnection of a headquarter with its subsidiaries,

IPsec implementations in software are not suitable to

fulﬁll high throughput requirements. In this case a

VPN gateway with hardware accelerated IPsec stack

will be used to perform the cryptographic operations.

The cryptographic keys in IPsec are negotiated us-

ing the Internet Key Exchange protocol (IKE). IKE is

deﬁned in (Kaufman, 2005) and negotiates security

parameters for the IPsec sessions. The key exchange

is based on the Difﬁe-Hellman key exchange proto-

col (DH) deﬁned in (Difﬁe and Hellman, 1976). DH

is based on the problem to solve the discrete loga-

rithm (Menezes et al., 1997). Up to now, no algorithm

is known, that is able to solve this problem in poly-

nomial time (Menezes et al., 1997). However using

short key update rates, the DH key exchanges increase

the network load and decrease the overall through-

put of the VPN by consuming much computational

power.

In our work, we focus on an efﬁcient VPN gate-

way that uses quantum key distribution (QKD) as an

alternative key exchange method in IKE. QKD is an

177

Neppach A., Pfaffel-Janser C., Wimberger I., Loruenser T., Meyenburg M., Szekely A. and Wolkerstorfer J. (2008).

KEY MANAGEMENT OF QUANTUM GENERATED KEYS IN IPSEC.

In Proceedings of the International Conference on Security and Cryptography, pages 177-183

DOI: 10.5220/0001926601770183

 SciTePress

Figure 1: Network Architecture.

emerging ﬁeld in security engineering. The technique

was invented in 1984 by C. Bennett and G. Brassard

(Bennett and Brassard, 1984) and enables theoreti-

cally secure distribution of random strings. The secu-

rity of QKD is based on the laws of quantum physics.

All practical attempts to eavesdrop QKD generated

keys can be noticed.

Using the QKD generated random strings, we im-

plemented a fast key update mechanism for the un-

derlying IPsec engine. The goal was to get a key

update rate of at least one key update per second.

Therefore, the prototype is implemented as a System-

on-Chip (SoC). The IPsec engine and parts of the

QKD module are implemented in conﬁgurable hard-

ware (Lorünser et al., 2008). This was mainly neces-

sary to accelerate encryption and to ofﬂoad constant

cryptographic tasks. The key management is imple-

mented in software.

The prototype can be used to get a basis of re-

quirements for QKD integration in existing applica-

tions using standardized interfaces. In this paper, we

focus on the key management approach, showing the

key management protocols and internal interconnec-

tion of key management related components.

In the remainder of this paper we present the over-

all architecture of the prototype in Section 2. Sec-

tion 3 describes the key management approach and

presents the adaptations of the IKE protocol. Sec-

tion 4 concludes the paper.

2 ARCHITECTURE

The overall network architecture of the prototype is

presented in Figure 1. The system acts as a security

gateway and provides an end point of a secured IP tun-

nel. All data arriving at gateway 1 from the protected

LAN is processed using a policy database. Depending

on the policy the data is either rejected, transferred in

plain or encrypted using the QKD generated keys.

Figure 2 shows the components of the VPN gate-

way solution. The QKD module generates the secure

random bit strings that are processed by a key man-

agement module. The key management approach is

based on a key distribution component and an adapta-

tion of the IKE protocol. Using IKE, so called secu-

rity associations (SAs) are established. These SAs are

SPDB

Key Man.

IPsec

SADB

MACMAC

QKD

Key-

store

WAN

Quantum System

LAN

Figure 2: Prototype Architecture.

stored in the security associations database (SADB)

and contain QKD generated keys that are used by the

IPsec engine to process arriving data packets. Details

about the QKD and IPsec hardware modules are pre-

sented in the next subsections. The key management

approaches are presented in Section 3.

2.1 QKD

The QKD sub-system is responsible for the genera-

tion of the shared secrets and it is used to replace

the original IKE scheme. In general, a quantum key-

exchange system provides provably secure distribu-

tion of random secrets over a quantum channel, which

can either be an optical ﬁbre link or a free-space line

of sight connection.

Light particles (photons) are encoded on one side

and transmitted to the second peer. After continu-

ously measuring the arriving photons the two par-

ties gain correlated data to establish a provably se-

cure shared secret. The distillation of the ﬁnal key out

of the correlations is done by means of software pro-

cessing and the implementation is referred to as QKD

stack.

Therefore, a complete QKD system consists of a

quantum optical segment, a data acquisition system

(DAQ) and a processing segment (QKD stack). The

latter requires an authenticated classical communica-

tion channel for ﬁnal key distillation which does not

need to be conﬁdential. The authentication is neces-

sary to prevent from man-in-the-middle attacks like it

is also the case in DH key exchange.

It is seen, that, in comparison to nowadays very

popular key exchange protocols and algorithms, QKD

needs a considerable hardware effort. We developed

electronics and a DAQ core for interfacing with en-

tangled QKD systems applying the BB84E protocol.

The DAQ unit is integrated in the SoC and can handle

up to 30 million events per second (MEvents) peak

rate with a timing resolution down to 80 picoseconds.

SECRYPT 2008 - International Conference on Security and Cryptography

178

The software processing for the QKD stack runs on

the integrated processor and it can generate up to 3

kbps ﬁnal key material.

QKD introduces a new quality for symmetric key

exchange primitives. It enables provable security and

high key-update rates. But it also has some drawback.

Due to the non-cloning theorem and the attenuation

QKD is limited in distance. The optical signal can-

not be repeated and the damped signals lead to lower

rates over distance. Current QKD links provide key

rates in the kilobit range over distances up to 100 km.

Moreover, some new protocols and advances in sin-

gle photon detection will allow for rates in the Mbps

region.

2.2 IPsec

The Internet Protocol Security (IPsec) suite of pro-

tocols deﬁnes a collection of standards to secure IP

trafﬁc. It provides a framework to secure commu-

nication at the network layer by adding authentica-

tion data and/or encryption to IP packets. Our im-

plementation supports only the Encapsulating Secu-

rity Payload (ESP) protocol in tunnel mode. ESP in

tunnel mode is the most useful setting for gateway-

to-gateway VPNs. It provides data authentication,

integrity and conﬁdentiality to IP packets. ESP en-

crypts the whole original packet and adds authentica-

tion data and an ESP header. Encrypted ESP packets

guarantee even the anonymity of sender and receiver

because this information is encrypted too. The ﬁnal

ESP packet contains the IP addresses of the two gate-

ways as source and destination address.

IPsec deﬁnes a bunch of symmetric ciphers. Our

implementation makes uses of the Advanced En-

cryption Standard (AES) (National Institute of Stan-

dards and Technology (NIST), 2001). In accor-

dance to the recommendations of VPN-B in (Hoff-

man, 2005) our implementation uses AES-128 in

CBC mode for data conﬁdentiality and AES-XCBC-

MAC-96 (Frankel and Herbert, 2003) for data authen-

tication. AES is processed by hardware modules.

The whole IPsec handling of the prototype is per-

formed by an IPsec ofﬂoad engine, as the power of

the embedded PowerPC CPU on the system-on-chip

is very limited. To support throughput rates in the

gigabit region, most components of the IPsec func-

tionality are implemented in hardware. The software

subsystem is only used to conﬁgure and monitor these

hardware modules.

The IPsec engine is composed of three main com-

ponents: A ﬁlter module, an encryption unit and a

routing module. The ﬁlter module holds a copy of the

security policy database (SPD) and decides if an ar-

riving IP packet should bypass the system, or if it has

to be encrypted/decrypted, or if needs to be discarded.

The encryption unit consist of a key store, which re-

sembles the SADB, and AES encryption and decryp-

tion modules. The key store can hold up to 32 SAs

per direction and manages their lifetime without soft-

ware interaction. After leaving the encryption unit,

the packets are forwarded to their destination gateway

by the routing module. Routing is necessary because

the destination IP address is known just after decrypt-

ing the ESP packet. The according Ethernet MAC

address of the destination has to be obtained for each

packet.

The software part of the IPsec engine runs on a

Linux 2.6 kernel. It is responsible for the conﬁgura-

tion of the hardware modules. The software receives

the conﬁguration and key material via the PF_KEY

interface. Hence it is compatible with all standard

IPsec key management implementations.

2.3 WBEM

VPN gateways offer complex functionality. Conﬁg-

uration of its services usually involves setting many

parameters on at least two endpoints. A secure man-

agement interface has to assure that the conﬁgurations

on all devices are synchronized. To prevent temporary

security holes a strict sequence of commands needs to

be executed. This is error-prone and leads to security

risks, especially when traditional conﬁguration tools

like secure shell (SSH) are used.

For this reasons, we decided to use Web-Based

Enterprise Management (WBEM) (DMTF, ) as man-

agement technology. It is one approach of solving

the management problem in heterogeneous networks.

WBEM is a set of standards that has been developed

by the Distributed Management Task Force (DMTF).

WBEM-based solutions provide out-of-the-box capa-

bilities to make policy deployment on different ma-

chines transparent to the user.

Our implementation uses the Small Footprint CIM

Broker (SFCB) from IBM (Standards Based Linux In-

strumentation, ) as WBEM server running on each

gateway. In addition we developed a graphical tool

that allows to easily conﬁgure and monitor VPN gate-

ways.

3 KEY MANAGEMENT

The presented key management approach focuses pri-

marily on high key update rates for IPsec. Addition-

ally, the management of the generated QKD keys is of

interest. Figure 3 shows the key related operations of

KEY MANAGEMENT OF QUANTUM GENERATED KEYS IN IPSEC

179

Figure 3: Key Management Overview.

Figure 4: QKD Software Architecture.

the prototype. First, the QKD module generates the

random bit strings and buffers them. This buffer is

accessed by a separate process (called Keymanager)

that establishes the end-to-end key buffers for local

applications. The Keymanager distributes the gener-

ated keys to registered applications and ensures that

key buffers of local and remote applications remain

synchronized. One of these applications is an adapta-

tion of the IKE protocol called QIKE. The main task

of QIKE is to negotiate SAs and parameters to reserve

a QKD key stream. Using the negotiated parameters,

a key buffer can be requested from the Keymanager

and the SADB can be ﬁlled with SAs containing QKD

generated keys. These SAs are used later on by the

IPsec module that processes arriving data packets.

3.1 QKD Key Generation

In our implementation the QKD sub-system is con-

tinuously generating secrets. The DAQ unit streams

the incoming raw data into a buffer and hands it over

to the QKD stack, which distills ﬁnal keys. The in-

coming raw data are sifted, error corrected, privacy

ampliﬁed and pushed into the keystore. We make use

of well established protocols and algorithms for the

QKD stack.

The necessary classical communication between

the two parties is managed over TCP/IP connections

Figure 5: Allocated key buffers.

in plaintext but authenticated. The software stack is

programmed under heavy usage of multi-processing

and Linux/Unix based interprocess communication to

optimize CPU and network usage. Its overall archi-

tecture is shown in 4.

During the sifting phase the bases of the protocol

are exchanged. VPN gateway 1 starts the process after

receiving a ﬁxed block of data from the measurement

core.

The data are then passed to the error correc-

tion stage, which run a performance optimized ver-

sion of the Cascade protocol (Brassard and Salvail,

1994). Optionally, the stack supports low density par-

ity checking (LDPC) as error correction scheme.

After correcting all errors and conﬁrmation of the

bit error rate, the stream enters the privacy ampliﬁca-

tion stage. This module shrinks the keys according

the amount of information revealed in the public con-

versation during the error correction and the error rate

itself. The privacy ampliﬁcation is in principle a para-

metric hash function based on the universal 2 classes

of hash functions. The keys are pushed into the key-

store over a very simple interface.

To prevent man-in-the-middle attacks all commu-

nication has to be authenticated and checked for in-

tegrity. This is done by applying message authenti-

cation codes (MAC) developed for theoretical secure

systems based on evaluation hashes (Shoup, 1996).

Therefore, all communication is routed through the

dedicated authentication module. It calculates and

veriﬁes the MAC tags. To do this it needs key ma-

terial itself.

3.2 Keymanager

The Keymanager is a multi-threaded server running as

a UNIX system daemon and is necessary to provide a

network layer for QKD. It is necessary to interconnect

several QKD links and, furthermore, to distribute the

continuous stream of keying material from the QKD

sub-system to different consuming applications.

SECRYPT 2008 - International Conference on Security and Cryptography

180

The Keymanager has two main types of threads.

Client threads handle local communication on the lo-

cal host and link threads establish connections to re-

mote hosts and manage the client threads’ key buffers.

The Keymanager is based on the master-slave prin-

ciple. The master is the one Keymanager with the

lower IP address. The communication between lo-

cal and remote Keymanager daemon is based on a bi-

nary TCP/IP protocol that is protected through con-

ﬁgurable hashed MACs (HMAC) against man-in-the-

middle attacks and through the inclusion of time tags

and message sequence counters against replay at-

tacks. The keys necessary for the HMAC are taken

from the quantum link.

During the initialization phase of the control chan-

nel, a pool of keys with a well known size is ﬁlled

on both keymanagers with keys from the QKD de-

vice (see communication key buffer in Figure 5). The

ﬁrst bits are used for authenticating the control chan-

nel and the second bits are stored for reset purposes.

The rest is used for the subsequent control messages.

In the basic conﬁguration the client listening port

is only active on the local host interface. Any attack

on the Keymanager would thus originate from the lo-

cal host which can be prevented more easily.

The message exchanges to establish common key

buffers for a local and remote application are pre-

sented in Figure 6. First, the client application regis-

ters to the client thread and submits an application ID

and the host address of the Keymanager the client is

registering to. If the application ID has already been

registered the call for registration fails. A wrong mes-

sage to the Keymanager results in a client’s termina-

tion to lower the risks of denial of service (DOS) at-

tacks.

Second, the client application sends a connec-

tion request containing the remote node’s address, the

maximum key length (maxlen) that will be requested,

the desired key rate (rate) and a timeout. If all those

parameters are valid and the requested key rate can

be satisﬁed by the local Keymanager, it either tries

to connect the client to the remote Keymanager if the

local node is the designated master or it queues the

client’s connect request until a valid connect request

from the remote Keymanager is received otherwise.

If the connection cannot be established to the remote

system within a deﬁned time interval, a timeout oc-

curs and the local client-Keymanager connection is

terminated.

After the connection phase, an application can

query its keystore to get the current ﬁll level or to get a

key of a speciﬁed length. If the requested length can-

not be satisﬁed only the amount available is returned.

The key data and the actual size of the data retrieved

Figure 6: Message ﬂow during connection establishment.

is sent back to the client.

Every client connection has associated key buffers

whose size can be calculated using Equation 1, where

time is the amount of time for which to try to hold

keying material.

bu f

size

= max(len

max

, time · rate) (1)

Whenever the ﬁll level of a key buffer drops below a

buffer threshold which can be calculated using Equa-

tion (2) with a conﬁgurable global threshold parame-

ter, a reﬁll procedure for all buffers is started.

bu f

threshold

= max(len

max

, size · global

threshold

) (2)

The key reﬁll procedure has the following prior-

ities. First, the key store to authenticate the mes-

sage exchanges between local Keymanager and re-

mote Keymanager is served. If keying material is

available, it is assigned to the client key stores with

a ﬁll level below their thresholds, according to their

registered key rate. If further keying material is left,

all remaining key stores are served in proportion to

their registered rate.

3.3 QIKE

The implementation of QIKE is based on Racoon,

a popular IKE daemon developed by the KAME

project (http://www.kame.net/racoon) and IPsec-

Tools (http://ipsec-tools.sourceforge.net). It is an

open source implementation and distributed under the

BSD license. Standard IKE consists of two phases.

In the ﬁrst phase, a so called ISAKMP SA is es-

tablished. ISAKMP means Internet security asso-

ciation key management protocol and is speciﬁed

in (D. Maughan and Turner, 1998). The ISAKMP SA

is used within the IKE protocol to protect all further

message exchanges in phase 2. The negotiated SAs in

Phase 2 are called IPsec SAs and are used to establish

an encrypted session between two IPsec end points.

The following subsections present the major adap-

tations of IKE to enable QKD support and high key

update rates.

KEY MANAGEMENT OF QUANTUM GENERATED KEYS IN IPSEC

181

3.3.1 Authentication in QIKE

In IKE, authentication of the communicating devices

is based on pre-shared key (PSK) or asymmetric cryp-

tography. Like already mentioned our solution is

based on QKD and thus uses the PSK approach. Sim-

ilar to one-time passwords, we use QKD random

strings for authentication purposes. The ﬁrst commu-

nication needs an initial shared pre-shared secret since

the communication to the Keymanager is triggered by

QIKE. After the ﬁrst Phase, a key buffer is requested

that is ﬁlled with new shared secrets obtained from

the QKD module.

3.3.2 Phase 1

The ﬁrst communication phase of QIKE is similar

to IKE. First, security association proposals are ex-

changed. A proposal contains parameters like encryp-

tion algorithm, authentication algorithm and key life-

time. Additionally, we introduced the QKD key rate

to be reserved and an application ID to establish a key

buffer using the Keymanager. After the ISAKMP SA

is negotiated, QIKE authenticates the messages using

the conﬁgured shared secret. If the authentication suc-

ceeds, the communication to the Keymanager starts.

The QIKE process registers on both sides to the Key-

manager using the application ID and the remote IP

address. Furthermore, the QKD key rate is used to

request a key buffer. If the both QIKE daemons per-

form their registration in time, a key buffer based on

the negotiated QKD key rate and the maximum key

size is allocated.

The maximum key size is computed using the

requirements of the negotiated encryption and au-

thentication algorithms. Using AES-128 for encryp-

tion (National Institute of Standards and Technology

(NIST), 2001) and AES-XCBC-MAC-96 for authen-

tication (Frankel and Herbert, 2003), a maximum key

size of 256 bits has to be requested (not consider-

ing the initialization vector for CBC encryption). Us-

ing a key lifetime in seconds or milliseconds, the key

rate can be computed without negotiation. However,

because of synchronization problems with lifetimes

in milliseconds, we decided to choose a lifetime in

bytes. Thus, the key rate varies depending on the uti-

lization.

3.3.3 Phase 2

To establish an IPsec SA another SA proposal ex-

change takes place. This exchange is protected by the

ISAKMP SA. The initiator sends an array of SA pro-

posals to the responder, which chooses an appropriate

one. Similar to Phase 1, the SA proposal contains

Figure 7: IPsec SADB and QKD Key Buffers.

beside the standard IKE parameters, QKD key rate,

an application ID and the maximum number of SAs

supported by the SADB. The IPsec SA generation is

based on the IKE Quick Mode.

The QKD key rate speciﬁes the rate that is re-

quested from the Keymanager. The application ID

identiﬁes the initiator and responder QIKE daemon.

The Keymanager uses these IDs and establishes the

requested application key buffers. For each direction

a separate buffer is allocated. Thus, the key buffer of

the outgoing IPsec connection of the initiator QIKE is

identical to the key buffer of the incoming IPsec con-

nection of the responder QIKE and vice versa (see

Figure 7).

The parameter of the maximum number of sup-

ported SA in the SADB is necessary to enable a high-

speed IPsec implementation. If the IPsec engine has

to wait for new key material, the throughput of the

prototype will be decreased. Therefore, multiple SAs

can be stored in the SADB. The SADB follows the

FIFO principle, in difference to the Linux SADB that

uses LIFO. Additionally, only SAs that are currently

in use can expire. In some SADB implementations,

the SA lifetime in time decreases as soon as the SA is

stored into the SADB.

Our solution uses a key lifetime in bytes, since

a lifetime in milliseconds will cause synchronization

problems. If a lifetime expires, the IPsec engine no-

tiﬁes QIKE using the PF_KEY interface. QIKE uses

this notiﬁcation and generates a new one by request-

ing new key material from the Keymanager. In differ-

ence to IKE, no renegotiation of the SA is performed.

This renegotiation is primarily necessary to exchange

new DH values and to trigger the remote IKE daemon

to check the SADB and to delete not expired SAs.

Instead of renegotiation of expired SAs, QIKE

is based on the ISAKMP informational messages.

These messages can contain delete notiﬁcations

that inform the remote daemon about expired SAs.

ISAKMP delete messages are unidirectional and

no response is expected from the remote daemon.

If QIKE receives a delete message, the SADB is

checked and not expired SAs are replaced with new

SECRYPT 2008 - International Conference on Security and Cryptography

182

Figure 8: Delete messages and SADB synchronization.

ones (see Figure 8). The ISAKMP informational mes-

sages are protected using the ISAKMP SA.

Nevertheless, synchronization problems can occur

if ISAKMP delete messages are lost. In our prototype,

we use increasing SPIs per connection. This gives the

possibility to resynchronize the SADB even if a delete

messages gets lost. The QIKE process checks the SPI

in the delete payload with the SPIs in the SADB and

can perform the SADB resynchronization by request-

ing the correct keys from the Keymanager. In IKE, it

is recommended that the SPI number is chosen ran-

domly. Up to our knowledge, this is primarily nec-

essary to circumvent DoS attacks using IPsec packets

with estimated SPIs. Because of the hardware imple-

mented IPsec engine, this type of attack is not appli-

cable to our prototype. The hardware can handle all

possible Gigabit scenarios and hence the performance

is not decreased. Another possibility to implement

random SPIs is to allocate a separate key buffer from

the Keymanager and to use the cryptographic keys as

SPIs.

4 CONCLUSIONS

In this work, we presented a prototype for QKD-

enabled IPsec. Up to our knowledge, it is the ﬁrst pro-

totype on such an advanced level that tries to integrate

QKD in a security gateway. To serve the demanding

throughput requirements of commercial applications,

many components of the system are implemented in

hardware. The presented key management approach

acts a starting point for further integration and devel-

opment approaches and veriﬁes that high key update

using QKD in IPsec are possible. Up to now, we

simulated a key update rate of one update per sec-

ond in software. The simulation was performed using

User Mode Linux and allows the simulation of com-

plete networks including hosts, clients and gateways

on a single PC. Further tests measuring the CPU con-

sumption and robustness against packet-loss will be

performed in the near future using the ﬁnal SoC pro-

totype.

REFERENCES

Bennett, C. H. and Brassard, G. (1984). Quantum Cryptog-

raphy: Public Key Distribution and Coin Tossing. In

Proceedings of International Conference on Comput-

ers, Systems and Signal Processing.

Brassard, G. and Salvail, L. (1994). Secret key reconcilia-

tion by public discussion. Lecture Notes in Computer

Science, 765:410–423.

D. Maughan, M. Schertler, M. S. and Turner, J. (1998). Rfc

2408: Internet security association and key manage-

ment protocol (isakmp).

Difﬁe, W. and Hellman, M. E. (1976). New directions in

cryptography. IEEE Transactions on Information The-

ory, IT-22(6):644–654.

DMTF. Web-Based Enterprise Management (WBEM).

website.

Frankel, S. and Herbert, H. (2003). RFC 3566: The AES-

XCBC-MAC-96 Algorithm and Its Use With IPsec.

RFC 3566 (Proposed Standard).

Hoffman, P. (2005). RFC 4308: Cryptographic Suites for

IPsec. RFC 4308 (Proposed Standard).

Kaufman, C. (2005). RFC 4306: Internet Key Exchange

(IKEv2) Protocol. RFC 4306 (Proposed Standard).

Kent, S. (2005). RFC 4303: IP Encapsulating Security Pay-

load (ESP). RFC 4303 (Proposed Standard).

Lorünser, T., Querasser, E., Matyus, T., Peev, M., , Wolk-

erstorfer, J., Hutter, M., Szekely, A., , Wimberger, I.,

Pfaffel-Janser, C., and Neppach, A. (2008). Security

Processor with Quantum Key Distribution.

Menezes, A. J., van Oorschot, P. C., and Vanstone, S. A.

(1997). Handbook of Applied Cryptography. Series

on Discrete Mathematics and its Applications. CRC

Press. ISBN 0-8493-8523-7.

National Institute of Standards and Technology (NIST)

(2001). FIPS-197: Advanced Encryption Standard.

Shoup, V. (1996). On fast and provably secure message au-

thentication based on universal hashing. Lecture Notes

in Computer Science, 1109:313–328.

Standards Based Linux Instrumentation. Small Footprint

CIM Broker (SFCB) Website. website.

KEY MANAGEMENT OF QUANTUM GENERATED KEYS IN IPSEC

183