cookie.pdf

(108 KB) Pobierz

A Secure Cookie Protocol

Alex X. Liu

, Jason M. Kovacs

Department of Computer Sciences

The University of Texas at Austin

Austin, Texas 78712-0233, U.S.A.

Chin-Tser Huang

Dept. of Computer Science and Engineering

University of South Carolina

Columbia, South Carolina 29208, U.S.A.

Mohamed G. Gouda

Department of Computer Sciences

The University of Texas at Austin

Austin, Texas 78712-0233, U.S.A.

{alex,

jmkovacs}@cs.utexas.edu

huangct@cse.sc.edu

gouda@cs.utexas.edu

Abstract

Cookies are the primary means for web applications

to authenticate HTTP requests and to maintain client

states. Many web applications (such as electronic com-

merce) demand a secure cookie protocol. Such a pro-

tocol needs to provide the following four services: au-

thentication, conﬁdentiality, integrity and anti-replay.

Several secure cookie protocols have been proposed in

previous literature; however, none of them are com-

pletely satisfactory. In this paper, we propose a secure

cookie protocol that is eﬀective, eﬃcient, and easy to

deploy. In terms of eﬀectiveness, our protocol provides

all of the above four security services. In terms of ef-

ﬁciency, our protocol does not involve any database

lookup or public key cryptography. In terms of deploy-

ability, our protocol can be easily deployed on an exist-

ing web server, and it does not require any change to

the Internet cookie speciﬁcation. We implemented our

secure cookie protocol using PHP, and the experimen-

tal results show that our protocol is very eﬃcient.

Web applications often use cookies to main-

tain state. A cookie is a piece of information that

records the state of a client. When a server needs to re-

member some state information for a client, the server

creates a cookie that contains the state informa-

tion and sends the cookie to the client. The client then

stores the cookie either in memory or on a hard disk.

The client later attaches the cookie to every subse-

quent request to the server.

Many web applications (such as electronic com-

merce) demand a secure cookie protocol. A secure

cookie protocol that runs between a client and a server

needs to provide the following four services: authenti-

cation, conﬁdentiality, integrity and anti-replay.

Authentication:

A secure cookie protocol should

allow the server to verify that the client has been

authenticated within a certain time period. More-

over, any client should not be able to forge a valid

cookie.

In secure web applications, a typical session

between a client and a server consists of two

phases. The ﬁrst phase is called the

and

the second phase is called the

subsequent-requests

phase.

In this phase, the client and the

server mutually authenticate each other. On one

hand, the client authenticates the server using the

server’s PKI (Public Key Infrastructure) Certiﬁ-

cate after he establishes an SSL (Secure Sockets

Layer) connection with the server. On the other

hand, the server authenticates the client using the

client’s user name and password, and sends a se-

cure cookie (which is also called an “authentica-

tion token” or an “authenticator” in previous lit-

erature) to the client.

Subsequent-requests Phase:

In this phase, the

client sends the secure cookie along with every re-

quest to the server; the server veriﬁes whether the

cookie is valid, and if it is, services the request.

1. Introduction

The widely used HTTP (Hypertext Transfer Proto-

col) works in a request-response fashion. First, a client

sends a request (which either asks for a ﬁle or invokes

a program) to a server. Second, the server processes

the request and sends back a response to the client.

After this, the connection between the client and the

server is dropped and forgotten. HTTP is stateless in

that an HTTP server treats each request independently

of any previous requests. However, many web applica-

tions built on top of HTTP need to be stateful. For ex-

ample, most online shopping applications need to keep

track of the shopping carts of their clients.

Alex X. Liu is the corresponding author of this paper.

333

Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply.

Conﬁdentiality:

The contents of a secure cookie

is intended only for the server to read. There are

two levels of conﬁdentiality that a secure cookie

protocol may achieve: low-level conﬁdentiality and

high-level conﬁdentiality.

(a)

Low-level Conﬁdentiality:

A secure cookie

protocol with low-level conﬁdentiality pre-

vents any parties except the server and the

client from reading the contents of a cookie.

To achieve low-level conﬁdentiality, a se-

cure cookie protocol usually runs on top of

SSL. Note that SSL encrypts every mes-

sage between the client and the server us-

ing a session key that only the client and

the server know. In this paper, we as-

sume that any secure cookie protocol runs

on top of SSL.

(b)

High-level Conﬁdentiality:

A secure cookie

protocol with high-level conﬁdentiality pre-

vents any parties except the server from read-

ing the sensitive information within a cookie

that the server does not want to reveal to the

client [8]. For example, the cookie’s contents

may contain some client information such as

their internal rating or credit score, which the

server may not want the client to be aware of.

Diﬀerent web applications may require diﬀerent

levels of conﬁdentiality. Therefore, a secure cookie

protocol should be able to support either low-level

conﬁdentiality or high-level conﬁdentiality conﬁg-

urations.

Integrity:

A secure cookie protocol should allow

a server to detect whether a cookie has been mod-

iﬁed.

Anti-replay:

In the case that an attacker replays

a stolen cookie, a secure cookie protocol should be

able to detect that the cookie is invalid. Other-

wise, the attacker would be authenticated as the

client that the replayed cookie was issued to.

In designing a secure cookie protocol, besides the

above security requirements, we also need to consider

the issues of eﬃciency and deployability. As for eﬃ-

ciency concerns, a secure cookie protocol should avoid

requiring a server to do database lookups in verifying

a cookie, and should avoid public key cryptography.

Note that database lookups dramatically slow down

the speed that a server takes to verify a cookie. As for

deployability concerns, a secure cookie protocol should

avoid requiring a client to possess a public key and a

private key, which is currently impractical to assume.

Several cookie protocols have been proposed [2, 5,

8, 10]; however, none of these protocols are completely

satisfactory. The cookie protocol in [5] has three weak-

nesses: it does not have a mechanism for providing

high-level conﬁdentiality, it is vulnerable to cookie re-

play attacks, and its mechanism for defending against

volume attacks is ineﬃcient and non-scalable. The

three authentication mechanisms of the cookie proto-

col in [8] are either ineﬀective or diﬃcult to deploy. The

cookie protocols in [2] and [10] are ineﬃcient because

they require database lookups in verifying a cookie.

In this paper, we propose a secure cookie protocol

that is eﬀective, eﬃcient, and easy to deploy. In terms

of eﬀectiveness, our secure cookie protocol provides all

of the above four security services. In terms of eﬃ-

ciency, our secure cookie protocol does not involve any

database lookup or public key cryptography. In terms

of deployability, our secure cookie protocol can be eas-

ily deployed on an existing web server, and it does not

require any change to the current Internet cookie spec-

iﬁcation [7].

The rest of this paper proceeds as follows. In Sec-

tion 2, we present our secure cookie protocol in detail.

In Section 3, we discuss the implementation of our se-

cure cookie protocol and its performance. In Section 4,

we review and examine existing cookie protocols. We

give concluding remarks in Section 5.

2. Secure Cookie Protocol

The state of the art of secure cookie protocols is the

one presented by Fu et al. in [5]. In this section, we ﬁrst

examine this protocol, which we refer as

Fu’s cookie pro-

tocol.

We show that this protocol has three major prob-

lems, and we give a solution to each of them. Finally,

we present our secure cookie protocol. The notations

used in this section are listed in the following table.

HMAC

(m,

(m)

Concatenation

Keyed-Hash Message Authentication

Code of message

using key

Server Key

Encryption of message

using key

Table 1: Notations

The keyed-hash message authentication codes used

in this paper are assumed to be

veriﬁable

and

non-

malleable:

given a message

and a key

it is com-

putationally cheap to compute

HMAC

(m,

k);

however,

given

HMAC

(m,

k),

it is computationally infeasible

to compute the message

and the key

Examples

of such keyed-hash message authentication codes are

HMAC-MD5 and HMAC-SHA1 [1, 4, 6, 9].

The server key (i.e.,

sk)

of a server is a secret key

that only the server knows.

334

Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply.

2.1. Fu’s Cookie Protocol

Fu’s cookie protocol is shown in Figure 1.

user name|expiration time|data

|HMAC(

user name|expiration time|data,

sk)

Figure 1. Fu’s Cookie Protocol

An attacker can register as a legitimate client with a

server and then gather a large number of cookies is-

sued by the server. If the data ﬁelds of all of these

cookies are encrypted by the same server key, the at-

tacker could possibly discover this key using cryptanal-

ysis. Although such cryptanalysis is hard, but, it is pru-

dent to avoid any such possibility.

The cookie protocol proposed in [10] manages cookie

speciﬁc encryption keys as follows. A server maintains a

database that stores the user name and the encryption

key of every client. When a server creates a cookie for

a client, the server generates a new random key for en-

crypting the cookie and replaces the old encryption key

associated with the client in the database with this new

key. When a server receives an encrypted cookie from

a client, the server uses the user name of the client to

search in the database for the corresponding encryp-

tion key. This solution has two major disadvantages.

First, it is highly ineﬃcient because of the overhead of

database lookups. Second, when the old encryption key

of a client is deleted, all the cookies that are encrypted

by the old encryption key become invalid. This could

be very destructive. A client may attach the same en-

crypted cookie to more than one request to a server.

The server may create a new cookie and a new encryp-

tion key for the client after the server receives the ﬁrst

request, which results all the other requests with the

same cookie being denied by the server.

The cookie protocol proposed in [8] manages cookie

speciﬁc encryption keys in a diﬀerent way: when a

server creates a cookie of high-level conﬁdentiality, the

server generates a random key, encrypts the key with

the server’s public key, and stores the encrypted key in

the cookie itself rather than a database on the server

side. The downside of this solution is the veriﬁcation

of every cookie involves public key cryptography, which

makes the cookie protocol complex and ineﬃcient.

Our solution to this problem is simple and eﬃcient.

We propose to use HMAC(user name|expiration time,

sk) as the encryption key. This solution has the fol-

lowing three good properties. First, the encryption key

is unique for each diﬀerent cookie because of the user

name and expiration time. Note that whenever a new

cookie is created, a new expiration time is included in

the cookie. Second, the encryption key is unforgeable

because the server key is kept secret. Third, the encryp-

tion key of each cookie does not require any storage on

the server side or within the cookie, rather, it is com-

puted by a server dynamically.

In this cookie protocol, a secure cookie that is issued

by a server to a client consists of the following four sub-

ﬁelds within the cookie value ﬁeld of the HTTP cookie

speciﬁcation.

User Name:

The value of this ﬁeld uniquely iden-

tiﬁes a user.

Expiration Time:

The value of this ﬁeld, which is

expressed as seconds past 1970 GMT, indicates

when this cookie will expire and the server should

reject it from a client.

Data:

The value of this ﬁeld can be anything that

the server wants to remember for the client when

the cookie is created. The state information (such

as the contents of an online shopping cart) of the

communication between the client and the server

is usually stored in this ﬁeld.

4. Keyed-Hash Message Authentication Code

(HMAC): The value of this ﬁeld is the keyed-hash

message authentication code of the above three

ﬁelds using the server key.

Fu’s cookie protocol has three major security weak-

nesses. First, it does not have a mechanism for provid-

ing high-level conﬁdentiality. Second, it is vulnerable

to cookie replay attacks. Third, its mechanism for de-

fending against volume attacks is ineﬃcient and non-

scalable. Next, we detail these three weaknesses and

give an eﬃcient and secure solution to each of them.

2.2. Problem I: Cookie Conﬁdentiality

We have discussed that some web applications need

high-level conﬁdentiality for their cookies. To pro-

vide high-level conﬁdentiality, a secure cookie proto-

col should encrypt the data ﬁeld of each cookie. Now

the question is this: which key should a server use for

this encryption?

Fu’s protocol does not provide an answer to this

question. There is only one key involved in Fu’s proto-

col, namely the server key. One straightforward solu-

tion is to use this server key to encrypt the data ﬁeld

of every cookie; however, this solution is not secure.

335

Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply.

2.3. Problem II: Replay Attacks

Fu’s cookie protocol is vulnerable to replay attacks,

which could be launched in the following two steps.

The ﬁrst step is to steal a cookie that a server issued

to another client. An attacker may have several ways

to steal a cookie from someone else. For example, if a

client stores a cookie in his hard disk, an attacker may

steal it using Trojans, worms, or viruses. An attacker

may steal a cookie by launching a Denning-Sacco At-

tack [3]. In such an attack, an attacker ﬁrst collects a

large number of messages that are encrypted by the

same SSL session key, and then obtains the SSL ses-

sion key using various methods. In the second step of

a replay attack, the attacker initiates an SSL connec-

tion with the server and replays a stolen cookie that

has not yet expired. Consequently, the server incor-

rectly authenticates the attacker as the spoofed client,

and allows the attacker to access the spoofed client’s

account.

To counter replay attacks, we propose to add the

SSL session key into the keyed-hash message authen-

tication code of a cookie, i.e., to use HMAC(user

name|expiration name|data|session key,

sk)

as the

keyed-hash message authentication code of each

cookie. Therefore, a cookie becomes session spe-

ciﬁc. Even if an attacker steals a cookie, he cannot suc-

cessfully replay it since the session key is known

only to a legitimate client and the server that cre-

ates the cookie.

val [t,

+ ∆], the server may receive legitimate cookies

that are created using either the old key

or the new

key

; therefore, if the cookie has not expired and the

cookie failed to be veriﬁed by the new key

, the server

has to use the old key

to verify the cookie. Clearly,

verifying cookies twice using two diﬀerent keys is in-

eﬃcient. Second, to make sure that the current server

key is changed to a new random key that has not been

used before, the server program has to be manually up-

dated and recompiled during key exchanges. Clearly,

this is not a scalable solution if the number of server

programs to be updated is large.

Our solution to this problem is eﬃcient and scal-

able. We propose to use the encryption key, namely

HMAC(user name|expiration time, sk), as the key in

computing the keyed-hash message authentication code

of each cookie. This solution has the following three

good properties. First, as discussed in Section 2.2, this

key is unique for each new cookie because of the user

name and expiration time. Second, this key is unforge-

able because of the server key. Third, because this

key is the same as the encryption, the computation

of HMAC(user name|expiration time, sk) only needs

to be done once.

2.5. Our Secure Cookie Protocol

Our secure cookie protocol is shown in Figure 2. Re-

call that (data)

denotes the encryption of the data us-

ing key

and

denotes the server key of a server.

user name|expiration time|(data)

|HMAC(

user name|expiration time|data|session key,

where

k=HMAC(user

name|expiration time,

sk)

Figure 2. Our Secure Cookie Protocol

2.4. Problem III: Volume Attacks

Using Fu’s cookie protocol, a server uses the same

server key in computing the HMAC of every cookie.

This makes the protocol potentially vulnerable to vol-

ume attacks. To launch volume attacks, an attacker

ﬁrst collects a large number of HMACs of diﬀerent mes-

sages where every HMAC is computed using the same

key; then the attacker discovers the key using various

methods. So far, HMAC-MD5 and HMAC-SHA1 are

not believed to be vulnerable to volume attacks [6],

however, as stated in [5], it is prudent to defend against

such attacks.

The solution proposed in [5] for defending against

volume attacks is to periodically change the server key.

However, this solution is ineﬃcient and non-scalable.

First, each time the server key is changed, the server

needs to use both the original key and the new key to

verify cookies for a certain period. Let

denote the time

that the server key is changed from

, and ∆ de-

note the largest expiration time that the server has is-

sued for a cookie before time

Thus, in the time inter-

Note that all of the four ﬁelds of user name, expira-

tion time, (data)

, and HMAC(user name|expiration

time|data|session key,

are within the cookie value

ﬁeld of the HTTP cookie speciﬁcation [7]. The two

ﬁelds of user name and expiration time are in plain

text because the server needs to use them to compute

HMAC(user name|expiration time,

sk).

Note that the

ﬁeld HMAC(user name|expiration time|data|session

key,

is used by our protocol to provide authentica-

tion, integrity, and anti-replay.

Our secure cookie protocol can be conﬁgured to pro-

vide either high-level or low-level conﬁdentiality. The

one shown in Figure 2 provides high-level conﬁdential-

ity. If low-level cookie conﬁdentiality is desired, one can

336

Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply.

simply leave the data ﬁeld unencrypted, i.e., replace

(data)

by the data in plain text.

The process for verifying a cookie created using our

protocol is shown in Figure 3. Note that if FALSE is

returned, the cookie is deemed invalid and the client

must login in again using his user name and password.

Cookie Veriﬁcation

Input

: A cookie

Output:

TRUE if the cookie is valid; FALSE otherwise

1. Compare the cookie’s expiration time and the server’s current

time. If the cookie has expired, then return FALSE.

2. Compute the encryption key as follows:

k=HMAC(user

name|expiration time, sk)

3. Decrypt the encrypted data using

4. Compute HMAC(user name|expiration time|data|session key,

k),

and compare it with the keyed-hash message authentication code

of the cookie. If they match, then return TRUE;

otherwise return FALSE.

processor, 512 MB RAM, and runs Microsoft Win-

dows 2003 Standard Edition, IIS 6.0, PHP 4.3.10 and

MySQL 3.23; and a client, which uses a 2.8 GHz Pen-

tium 4, 512 MB RAM, and runs Red Hat 3.0. The

server and the client are connected by a dedicated Gi-

gabit link with a 0.9 ms round-trip time.

We run each of the ﬁve cookie protocols over SSL

connections between the client and the server. For each

protocol, the client made 10,000 successive requests to

the server, where each request has an attached cookie.

We measure on the client side the average time from

when a request was sent to when a response was re-

ceived. In our implementations, the server creates a

new cookie after it receives a valid cookie. In other

words, the end-to-end latency that we measured con-

sists of: (1) the time for transferring a request with a

cookie from the client to the server, (2) the time for the

server to verify the cookie in the request, (3) the time

for the server to create a new cookie, and (4) the time

for transferring a response with a new cookie from the

server to the client. The overall size of each request in-

cluding HTTP headers is on average 1KB. The exper-

imental results are shown in Figure 4.

Figure 3. Cookie Veriﬁcation

3. Implementation and Performance

In this section, we discuss the implementation and

performance issues of our secure cookie protocol. To

measure the performance of our secure cookie proto-

col in comparison to Fu’s cookie protocol, we devel-

oped the following four implementations in PHP: (1)

Fu’s cookie protocol with low-level conﬁdentiality, (2)

Our cookie protocol with low-level conﬁdentiality, (3)

Fu’s cookie protocol with high-level conﬁdentiality, (4)

Our cookie protocol with high-level conﬁdentiality.

Since Fu’s cookie protocol does not provide high-

level conﬁdentiality, for performance evaluation pur-

poses, we assume that the data ﬁeld of a cookie is en-

crypted with the server key. In order to provide a base-

line for comparison, we also implemented an insecure

cookie protocol in which no cookie has any message

authentication code or has any encryption, i.e., each

cookie contains only the following three ﬁelds in plain

text: user name, expiration time, and data.

Here we discuss some details of the implementation

of the above cookie protocols. We use HMAC-SHA1

(in the Crypt

HMAC package of the PEAR PHP li-

brary) as the keyed-hash message authentication code

function. We use the Rijndael-256 algorithm (in the

mcrypt library) through ECB (Electronic Code Book)

mode as the encryption algorithm. The server key con-

sists of 160 bits. Every keyed-hash message authenti-

cation code output consists of 320 bits.

Our test environment consists of a medium-loaded

commercial web server, which uses a 2.4 GHz Celeron

Average Latency over SSL (ms)

Insecure Cookie Protocol

Fu's Cookie Protocol with Low-level Confidentiality

Our Cookie Protocol with Low-level Confidentiality

Fu's Cookie Protocol with High-level Confidentiality

Our Cookie Protocol with High-level Confidentiality

42.66

39.11

45.36

45.89

Figure 4. End-to-end Performance Comparison

From the data in Figure 4, we can see that the per-

formance of our secure cookie protocol is very close to

that of Fu’s cookie scheme, while our secure cookie pro-

tocol provides better security.

337

Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply.

Plik z chomika:

wp79

Inne pliki z tego folderu:

-launch-icarscan-user-manual.pdf (1627 KB)
1.0-VVDI2-Outline-V1.0.pdf (991 KB)
1.1-VVDI2-Installing-the-software-and-drivers-V1.0.pdf (755 KB)
1.2-VVDI2-Volkswagen-Description-V1.1.pdf (534 KB)
1.6-VVDI2-update-online-V1.0.pdf (539 KB)

cookie.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: