On secure and pseudonymous client-relationships with multiple servers.
This paper introduces a cryptographic engine, Janus, which assists clients in establishing and maintaining secure and pseudonymous relationships with multiple servers. The setting is such that clients reside on a particular subnet (e.g., corporate intranet, ISP) and the servers reside anywhere on the Internet. The Janus engine allows each client-server relationship to use either weak or strong authentication on each interaction. At the same time, each interaction preserves privacy by neither revealing a clients true identity (except for the subnet) nor the set of servers with which a particular client interacts. Furthermore, clients do not need any secure long-term memory, enabling scalability and mobility. The interaction model extends to allow servers to send data back to clients via e-mail at a later date. Hence, our results complement the functionality of current network anonymity tools and remailers. The paper also describes the design and implementation of the Lucent Personalized Web Assistant (LPWA), which is a practical system that provides secure and pseudonymous relations with multiple servers on the Internet. LPWA employs the Janus function to generate site-specific person?, which consist of alias usernames, passwords, and e-mail addresses.
Introduction
We consider the following problem: there is a set
of clients located on a particular subnet and a set
of servers on the Internet. For example, the set
of clients could be employees on a company's intranet
or subscribers of an ISP and the servers could
be Web-sites. See Figure 1, where c i are clients
and s j are server. A client wishes to establish a
persistent relationship with some (or all) of these
servers, such that in all subsequent interactions (1)
the client can be recognized and (2) either weak or
strong authentication can be used. At the same
time, clients may not want to reveal their true identity
nor enable these servers to determine the set
of servers each client has interacted with so far (es-
tablishing a dossier). This last property is often
called pseudonymity to denote persistent anonymity.
Equivalently, a client does not want a server to infer
through a relationship more than the subnet,
on which the client is located nor connect different
relationships to the same client. This paper introduces
a client-based cryptographic engine, which
allows a client to efficiently and transparently establish
and maintain such relationships using a single
secret passphrase. Finally, we extend our setting to
include the possibility of a server sending data via
e-mail to a client.
We consider the specification and construction of
a cryptographic function that is designed to assist
in obtaining the above goal. Such a function needs
to provide a client, given a single passphrase, with
either a password (weak authentication) or a secret
(strong authentication) for each relation-
ship. Furthermore, a username might be needed
too, by which a client is (publicly) known at a server.
Such passwords, secret keys, and usernames should
neither reveal the client's true identity nor enable
servers to establish a dossier on the client. We name
such a cryptographic function (engine) the Janus
function (engine). We will briefly review that simple
choices for Janus , such as collision-resistant hash
function are not secure for our purposes and conse-
quently, we will show a Janus function that is more
robust. We will also show how to implement a mailbox
system on the client side, such that a server can
send e-mail to a client without requiring any more
information than for client authentication.
1.1 Related Work and Positioning of
our Work
Network anonymity is being extensively studied
(see, e.g., [PW85, GWB97]). For example, Simon
in [S96] gives a precise definition for an Anonymous
Exchange Protocol allowing parties to send individual
messages to each other anonymously and to reply
to a received message. Implementation efforts
for approximating anonymous networks are being
carried out by several research groups (e.g., anonymous
routing [SGR97] and anonymous Web traffic
[SGR97, RR97]). Besides that, there are several
anonymous remailers available for either e-mail
communication (see, e.g., [GWB97, GT96, B96,
E96]) or Web browsing (see, e.g., [Anon]). We will
discuss some of these in more detail later.
We view our goal as complementary: All of the
above work tries to find methods and systems to
make the Internet an (approximate) anonymous net-
work. This is a hard task and consequently the resulting
tools are rather difficult to use and carry
some performance penalties. We focus on a method
for assisting a client to interact with multiple servers
easily and efficiently, such that the server cannot infer
the identity of the clients among all clients in a
given subnet, but at the same time the client can
be recognized and authenticated on repeat visits.
We do not address communication between a sub-net
and a server. Consequently, a server can easily
obtain the particular subnet in which a client is lo-
cated. In many cases, this degree of anonymity is
sufficient, for example, if the client is a subscriber
of a large ISP, or an employee of a large company.
In the language of Reiter and Rubin ([RR97]), the
anonymity of such a client is somewhere between
probable innocence and beyond suspicion. Alterna-
tively, our method can be used in conjunction with
existing remailers to enable a client to interact with
a server without revealing the particular subnet.
We elaborate on this point in Section 2 for client-initiated
traffic and in Section 4.3 for server initiated
traffic. The work closest in spirit to the Janus engine
are the visionary papers of Chaum [C81, C85]
on digital pseudonyms.
In [GGMM97], we described the design and impl-
mentation of a Web-proxy which assists clients with
registering at multiple Web-servers. In this paper,
we focus on a new, simpler, and provably correct
construction of the Janus engine, a new and different
method of conveying anonymous email that
greatly reduces the required trust in the interme-
diary, and a discussion of moving features to shift
trust from a proxy to the client's machine. The latter
allows, for example, to integrate a Janus engine
with the P3P proposal, giving the client the power
to use pseudonymous P3P personae (see Section 5).
Thus, our methods and design are applicable to any
client server interactions, well beyond the proxied
Web browsing for server registration of [GGMM97].
Organization of the rest of the paper: In Section
2 we describe our interaction model and our
function requirements. Section 3 contains a detailed
description of the Janus function. Section 4 extends
the model of interaction to allow servers to send
data to clients' anonymous mailboxes. Section 5
presents various applications and configurations and
discusses some of the trade-offs involved.
Model and Specifications
We present here the framework for interaction between
clients and servers, and the way in which the
Janus engine is incorporated within such interac-
tion. There is a set of clients
and a set of servers g. Each
client can interact with any server. Interaction can
take place in one of the following two ways:
ffl Client initiated: A client c i decides to contact a
server s j . The server s j requires c i to present a
username and a password (secret shared key) at
the beginning of this interaction to be used for
identification and weak (strong) authentication
on repeat visits.
ffl Server initiated: A server s j decides to send
some data to a client c i which has contacted s j
at some earlier point in time (using the client's
username).
Individual clients may wish to remain anonymous
in the above interaction; i.e., a client does not want
to reveal his/her real identity c i to a server (beyond
the particular subnet, in which c i resides).
Client-initiated interaction: A client c i , on a
first visit presents to a server s j an alias a i;j , which
includes a username and either a password or a
key. On repeat visits a client simply presents the
password again for weak authentication or uses the
key with a message authentication code (MAC) for
strong authentication (see [MMS97]). We would like
the alias a i;j to depend on c i , s j , and p i a secret
client passphrase. Since we want this translation of
names to be computable, we define a function which
takes c i , p i and s j , and returns an alias a i;j . This
function is called the Janus function, and is denoted
J . In order to be useful in this context, the Janus
function has to fulfill a number of properties:
1. Form properties: For each server, J provides
each client with a consistent alias, so that
a client, by giving her unique identity and
Firewall
ISP Access
c3
Janus
mailboxes
c1, p1
c2, p2
c3, p3
a11, a21, a31
a12, a22, a32
a13, a23, a33
a14, a24, a34,
engine
Gateway

Figure

1: Client Server Configuration with Janus
Engine on the Gateway
passphrase, can be recognized and authenticated
on repeat visits. J should be efficiently
computable given c i , p i , and s j . The alias needs
to be accepted by the server; e.g., each of its
components must have appropriate length and
range.
2. Secrecy of
passwords/keys: Alias passwords/keys remain
secret at all times. In particular, an alias username
does not reveal information on any alias
password/key.
3. Uniqueness of aliases among clients & Impersonation
resistance: Given a client's identity
and/or his alias username on a server s j a third
party can guess the corresponding password
only with negligible probability. Moreover, the
distribution of the alias usernames should be
such that only with negligible probability two
different users have the same alias username on
the same server.
4. Anonymity / Uncheckability of clients: The
identity of the client is kept secret; that is,
a server, or a coalition of servers, cannot determine
the true identity of the client from
his/her alias(es). Furthermore, it is not checkable
whether a particular client is registered at
a given server.
5. Modular security & Protection from creation of
dossiers: An alias of a client for one server does
not reveal any information about an alias of
the same client for another server. This also
implies that a coalition of servers is unable to
Firewall
ISP Access
c3 mailboxes
a11, a21, a31
a12, a22, a32
a13, a23, a33
a14, a24, a34,
Gateway
proxy
a11, a12, a13,a14
a21,a22
a23,a24

Figure

2: Client Server Configuration with Local
Janus Engine
build a client's profile (dossier) based on the
set of servers with which he/she interacted by
simply observing and collecting aliases.
One possible physical location to implement the
Janus function is on the gateway. See Figure 1,
where we refer to the implementation as the Janus
engine. Clients provide their identity c i and secret
passphrase p i to the gateway, where the translation
takes place. An alternative location for the Janus
engine is on each client's machine, as depicted in

Figure

2, where the locally generated aliases are sent
to the server via the gateway. See Section 5 for a
discussion of trade-offs. The following property is
of practical significance, as it provides robustness
against the possibility to recover privacy-sensitive
information "after the fact":
6. Forward Secrecy: When a client is not interacting
with a server, the Janus engine does
not maintain in memory any information that
may compromise on the above properties of the
Janus function. This excludes the simple approach
of implementing a Janus function by a
look-up table.
Consequently, an entity tapping into a (gateway)
machine on the subnet, cannot infer any useful in-
formation, unless it captures a client's passphrase
(which is never transmitted in Figure 2). Forward
Secrecy also enables a client to use different Janus
engines within her subnet, given that she remembers
her passphrase (mobility).
If a client desires to hide her subnet from a server,
she can easily combine our method with other
anonymity tools. For example, if she contacts a
server via the Web (HTTP), she can use either
Onion Routing ( [SGR97]) or Crowds ( [RR97]). In
the first case, the connection from the gateway to
the server is routed and encrypted similar to the
methods used by type I/II remailers (see also Section
4.3) and in the second case her connection is
"randomly" routed among members (on different
subnets) of a crowd.
Server-initiated interaction: A server knows a
client only by the alias presented in a previous,
client-initiated interaction. We allow a server s j
wishing to send data to client c i , known to it as
a i;j , to send an e-mail message to the corresponding
subnet, addressed to the username component
u of a i;j . The message is received by the Janus en-
gine, see Figure 1, which will make sure that the
message is delivered to the appropriate client, or is
stored by the gateway, until a local Janus engine retrieves
the messages, as in Figure 2. Our scheme of
storing mailboxes maintains forward secrecy. More
details are in Section 4, where it is also shown, how
server-initiated interaction can be combined with
pseudonymous remailers.
3 The Janus function
In this section we present the Janus function in de-
tail. We first develop our requirements, then discuss
some possible constructions.
The Setting of the Janus-function: A client inputs
her identity c i , her secret passphrase p i , the
identity of the server s j , and a tag t indicating
the purpose of the resulting value. Depending on
this tag, the Janus function returns either an alias-
username a u
i;j for the user c i on the server s j or the
corresponding password a p
i;j . Note that it would be
easily possible to extent this function to generate
secret values for other purposes (see also [MMS97]).
Adversarial Model: We assume that a client c i
does not reveal her passphrase p i to anyone 1 . How-
ever, we allow that an adversary E can collect pairs
(a u
i;j ) and the corresponding server names s j .
Note that registered alias usernames may be publicly
available on some servers and that we can not
assume that all servers can be trusted or store the
passwords securely. In some cases it might even be
possible to deduce the clients name c i (e.g. from the
data exchanged during a session, or simply because
the client wishes to disclose his identity) and we also
1 except to the Janus engine
have to assume that a chosen message attack is possible
(e.g. by suggesting to a client c i to register
on a specific server). Roughly speaking, we will require
that an adversary does not learn more useful
information from the Janus function than he would
learn if the client would chose all his passphrases
and aliases randomly.
3.1 Janus function specifications
We say that a client c i is corrupted
if the adversary E has been able to find p i . We say
that c i is opened with respect to a server s j if the
(a u
i;j ) has been computed and used. (Note
that if c i has been opened with respect to a server
then an adversary E may know only (a u
but not necessarily c i .) We say that c i has been
identifiably opened with respect to a server s j
if an adversary knows (a u
together with the
corresponding c i .
Let C be the set of clients, S be the set of servers,
P be the set of allowable client secret passwords,
AU be the set of allowable alias usernames, and let
AP be the set of allowable alias passwords. Let
k be the security parameter of our Janus function
meaning that a successful attack requires about 2 k
operations on average. Let the Janus function be
Since usernames and passwords normally consist
of a restricted set of printable characters we also
need two functions that simply convert general k-bit
strings into an appropriate set of ASCII strings.
Thus
be two injective functions that map k-bit strings
into the set of allowable usernames and passwords.
. The client's identity a u
i;j and
password a p
i;j for the server s j are then computed
by
a u
a p
The two functions U and P are publicly known,
easy to compute and we may assume easy to invert.
Thus knowing U (x) of some x is as good as knowing
x. In particular if an adversary can guess U (x) then
he can guess x with the same probability.
Following our adversarial model, the Janus function
has to satisfy the following requirement:
1. Secrecy: Given a server s j , an uncorrupted and
not identifiably opened client c i and t 2 fp; ug,
the adversary E cannot find J
nonnegligible probability even under a chosen
message attack, that is under the assumption
that the adversary can get J
any s j 0
2. Anonymity: Given a server s j , two uncorrupted
clients that are not opened with
respect to s j and t 2 fp; ug. Then an adversary
cannot distinguish J
even under a chosen message attack, that is
under the assumption that the adversary can
get J any list of arguments not
used above.
It should be noted that the two requirements are indeed
different. For example if we were to implement
the function J using a digital signature scheme,
i.e., J
then the first
requirement would be satisfied, but the second one
clearly isn't since the clients identity could be found
by checking signatures. One the other hand a constant
function satisfies the second requirement, but
not the first one.
Moreover, it should be noted that our requirements
are stated in a rather general form. In particular,
the first requirement states that no result of the
Janus function can be derived from other results.
This implies the secrecy of passwords, impersonation
resistance and modular security.
3.2 Possible Constructions for J
Assume that ' c is the maximal bit length of c i , ' s
the maximal length of s j , ' p the maximal length
of p i and ' t the number of bits required to encode
the tag t. Throughout this section we will assume
that all inputs c are padded to their maximal
length. This will assure that the string c i jjs j jjp i jjt
is not ambiguous.
Given the function specification, an ideal construction
would be via a pseudorandom function f :
. Unfortunately, there
are no known implementations of pseudorandom
functions. Typically, they are approximated via either
strong hash functions or message authentication
codes (MAC), even though, strictly speaking,
the definitions of these primitives do not require
them to be pseudorandom. In the following sec-
tions, we are going to examine both options and
give some justifications for preferring a MAC based
solution over other tempting constructions.
3.2.1 Using hash functions
One possible attempt might be to use the hash of
the inputs h(c i jjs j jjp i jjt) as our function. However,
hash functions are not designed to keep their inputs
secret. Even if it is hard to invert the hash function
for a given input, it might still be possible to derive
different servers s j .
A hash function that is weak in that respect can
for example be found in [A93]. Some apparently
better constructions for keyed functions based on
hash functions have been proposed (e.g., MDx-MAC
[PO95]). But our requirements are quite different
from the goals of these constructions. Therefore,
we decided not to use hash functions for our Janus
function.
3.2.2 MACs
A much more promising approach is the use of message
authentication codes (MACs). In particular if
MACK (x) denotes the MAC of the message x under
the key K then we can define a potential Janus
function as
This approach has the advantage that some of our
requirements are already met. In particular if the
MAC is secure then the secrecy of passwords and
impersonation resistance for the Janus function are
implied. Other requirements, like consistency, efficient
computation of the function, single secret and
acceptability, are just consequences of the actual implementation
of the Janus function and the mappings
U and P . The only additional requirement
is the anonymity of clients.
To this end, we consider the following result of Bel-
lare, Kilian, and Rogaway ([BKR94]): Let
xm be a message consisting of m blocks x i
of size ' bits. Given a block cipher
denotes the key, define the CBC-
MAC by
Assume that an adversary can distinguish a MACK
from a random function with an advantage ffl by running
an algorithm in time t and making q queries to
an oracle that evaluates either MACK or the random
function. Then the adversary can distinguish
fK from a random function running an algorithm
of about the same size and time complexity having
an advantage of ffl \Gamma Hence, if we use
CBC-MACs, then anonymity is just a consequence
of [BKR94].
If the underlying block cipher fK behaves like a
pseudorandom function then the above result shows
that a birthday attack is almost the best possible at-
tack. In particular an attacker can do not much better
than collecting outputs of the function and hoping
for an internal collision, i.e. two messages x; y
such that fK (f K
for some i ! m. In that case the attacker would
know that replacing the first i blocks in any message
starting with x would result in
another message having the same hash value.
We thus caution that a block cipher with '-bit block
size should not be used if an attacker can collect
about MACs. Concretely, block ciphers
having 64-bit blocks, such as DES, triple-DES, or
IDEA [LM91] should not be used if it is feasible for
an attacker to collect about 2 32 samples, thus giving
only marginal security to the overall scheme.
However, newer block ciphers, such as SQUARE
[DKR97] and one variant of RC5 [R95] have 128-
bit block sizes and are therefore more suitable in
this case.
Anonymous mailbox system
We first briefly recall the history of anonymous re-
mailers, then show our anonymous mailbox system
and finally inidcate how the two can be usefully
combined.
4.1 Brief History of Anonymous E-mail
Tools for anonymous e-mail communication have
been around for a few years by now (see,
e.g, [GWB97, B96, GT96, E96]. Early anonymous
remailers (Type 0, e.g., Anon.penet.fi) accepted
e-mail messages by a user, translated them to a
unique ID and forwarded them to the intended re-
cipient. The recipient could use the ID to reply
to the sender of the message. The level of security
of this type of remailer was rather low, since it
did not use encryption and kept a plain text (trans-
lation) database. A next (and still current) generation
of remailers (Type I, Cypherpunk remail-
ers) simply take a user's e-mail message, strip off
all headers and send it to the intended recipient.
The user can furthermore encrypt the message before
sending it and the remailer will decrypt the
message before processing it. For enhanced secu-
rity, a user can chain such remailers. In order to
use a chain r of remailers, a user first encrypts
the message for r 2 and then for r 1 . (see also the efforts
on Onion Routing, [SGR97]). Still, even such
a scheme is susceptible to traffic analysis, spam and
replay attacks. Mixmaster remailers (Type II) are
designed to withstand even these elaborate attacks.
This development of remailer yields more and more
intraceable way of sending messages, but it gives
no way to reply to a message. This gives rise to
"pseudonymous / nym" remailers, which, in a nut-
shell, work as follows: A user chooses a pseudonym
(nym), which has to be unused (at that remailer).
Then the user creates a public/private key pair for
that nym. When sending a message, the user encrypts
with the server's public key and signs a message
with her private key. The recipient can reply
to the message using the nym. Some remailers store
the message and the original sender can retrieve this
mail by sending a signed command to the remailer,
other remailers directly forward the message by using
a "reply block", an encrypted file with the user's
real email.
The ultimate goal of all these remailers is to enable
e-mail communication as if the Internet were
an anonymous network. This is a very hard task
and consequently these tools induce a performance
penalty and are rather difficult to use.
4.2 Anonymous Mailboxes
In this section, we show how to construct an anonymous
mailbox system within our model. As before,
we assume that the users are in a particular sub-
net. Our goal is to provide these users (clients) with
a transparent way to give e-mail addresses to outside
parties (servers), which maintain the properties
of the aliases (anonymity, protection from dossiers,
etc). For example, a client might want to register
at a (Web-site) server for mailing-lists, personalized
news, etc. Such an e-mail address provides a server
with the means to initiate interaction with a client
by sending an e-mail message to the client.
We first consider a setting with the Janus engine on
the gateway (Figure 1). We propose that the Janus
engine computes "a u
i;j @subnet-domain" as c i 's e-mail
address to be used with s j . We further suggest
storing a mailbox for each such active
the subnet's gateway, such that an owner of a mailbox
is only identified by the respective alias. Messages
are stored in these mailboxes, passively awaiting
clients to access them for retrieval. We require
that (1) given a previous, client-initiated interac-
tion, a server can send data to the mailbox created
for the (client, server) pair, (2) the Janus engine
(upon being presented with client c i
retrieve the messages in all of her mailboxes without
remembering a corresponding list of servers, (3)
neither the Janus engine nor the mailboxes compromise
on the "Forward Secrecy" property. We show
that the Janus function can be used to overcome
the apparent contradiction of requirements (2) and
(3). Note that the secrecy of the actual data stored
within a mailbox is an orthogonal issue and can be
solved, for example, by using PGP. For the setting
of a Janus engine on each client (Figure 2), most of
the scheme above remains unchanged with one important
exception: When a client wants to retrieve
her messages, the local Janus engine instructs the
gatewaway, which mailboxes to access and hence p i
is never revealed to the gateway.
Data Structures for
a m
m)), where we extend J to
have m as a new tag for "mail index", n i an integer
indexing c i mailboxes, and M a corresponding
injective function to map the output of J into a suitable
range. We explain the extensions in turn below.
The following record R is stored with the
mailbox. R has three fields: (1) R alias = a u
, . The argument n i in (2)
indicates the index of the mailbox created for client
. The record R (and consequently
the mailbox) can be accessed both via R alias
or R index . The R alias field contains the name of the
mailbox that is used for messages sent from s j to the
client c i . A second data structure, stored together
with the mailboxes, holds a counter C i for each of
the clients is the number of mailboxes the
client established so far. These counters
are initialized to 0. Note that . The
counter itself is indexed by a m
i;0 , so that the Janus
engine, upon being presented with
find it.
Creating a Mailbox: Whenever the client c i instructs
the Janus engine to give out an e-mail address
for s j , the engine checks if a record R with
i;j already exists in the first data struc-
ture. If it does not exist, then the engine retrieves
the counter C i by accessing the second data structure
with the key a m
i;0 . If no C i is found, it is initialized
to zero. The counter C i is incremented and
a new record is R created,
Afterwards, the engine
stores the updated value of C i in the second data
structure with key a m
i;0 . Finally, the Janus engine
create a new mailbox under the name of R alias .
Retrieving Mail: Whenever client c i connects to
the Janus engine, it will retrieve all of c i 's accumulated
e-mail messages. The engine first retrieves the
counter C i by accessing the second data structure
with the key a m
i;0 . Then it retrieves all records R
. For each such
and presents it, together with R s , to the client c i .
The above scheme constitutes a service to store mail
for any client and allows a client c i to retrieve all her
mail upon presenting uncorrupted
and not identifiably opened with respect to server
do better than guessing
the identity of the corresponding mailbox. Further-
more, given any two such mailboxes, E cannot do
better than guessing whether they have the same
owner. This is a simple consequence of the properties
of the Janus function J .
The above system can easily be extended to allow
a client to actively send e-mail to servers using the
Janus engine to generate a different address depending
on the server.
4.3 Combining our Solution with
Pseudonymous Remailers
When we allow the adversary to execute more elaborate
attacks (than we introduced in our model of
Section 3), such as eavesdropping or traffic analysis,
a client visiting several servers within a short period
of time, might become vulnerable to correlation
and building of dossiers (albeit not to compromise of
anonymity). Also, if a client happens to reside on a
small subnet, the subnet's population might not be
large enough to protect her identity. In these cases,
it makes sense to combine our method with anonymous
remailers or routing (for Web traffic) for enhanced
protection: We can view the Janus engine as
a client's ``front end'' to a pseudonymous remailer.
It computes the different nyms on a client's behalf
and presents them to the remailer. It manages all
the client's mailboxes and presents incoming messages
to the client. It also manages a client's pub-
lic/private keys for each nym. Furthermore, even
the remailer closest to the client (of a possible chain)
can neither infer the client's identity nor correlate
different aliases. All this remailer sees (when decrypting
a reply block) is the client's alias e-mail
address.
5 Trade-Offs and Applications
In this secton we examine the trade-off between the
configurations corresponding to Figure 1, which we
refer to as the gateway approach and to Figure 2,
which we refer to as the local approach. We then
present a few concrete applications.
The basic advantage of the local approach is that
the Janus functionality is pulled all the way to
the client's machine, minimizing outside trust.
Thus, the client does not have to reveal her secret
passphrase to another machine (the gateway). A
client also has the flexibility to choose a mailbox location
outside her own subnet, minimizing the trust
in the subnet (e.g., the client's ISP). There are also a
number of scenarios, where the Janus functionality
is required to be on the client's machine: For exam-
ple, in the realm of Web browsing, the Janus engine
can be integrated with the Personal Privacy Preferences
standard proposal to make a P3P persona
(see [P3P]) pseudonymous: P3P enables Web
sites to express privacy practices and clients to express
their preferences about those practices. A P3P
interaction will result in an agreement between the
service and the client regarding the practices associated
with a client's implicit (i.e., click stream) or
explicit (i.e., client answered) data. The latter is
taken from data stored in a repository on the client's
machine, so that the client need not repeatedly enter
frequently solicited information. A persona is
the combination of a set of client preferences and
P3P data. Currently, P3P does not have any mechanisms
to assist clients to create pseudonymous per-
sonae. For example, a client can choose whether to
reveal his/her real e-mail address, stored in the the
repository. If the e-mail address is not revealed, the
Web-site cannot communicate with the client and
if the e-mail address is indeed revealed, the Web-site
has a very good indication on the identity of
the visitor. Using a Janus engine provides a new
and useful middle ground: The data in repository
corresponding to usernames, passwords, e-mail ad-
dresses, and possibly other fields can be replaced by
macros which, by calling the Janus engine, expand
to different values for different Web-sites and thus
create a pseudonymous personae for the client.
For the case of the gateway approach, we note that
the Janus engine does not have to be distributed
throughout the subnet. Thus, the clients do not
have to download or install any software and no
maintaince is required, also giving scalability: when
the population in the subnet grows, it enables to
easily add gateway machines (helped by Forward
Secrecy property). The proxy might also provide
alias management capabilities in the case where the
gateway is for a corporate intranet: Such capabilities
might include two clients to share their aliases
for all the servers, a client to transfer one or more of
his/her aliases to another client, or even two clients
to selectively share some of their aliases. For ex-
ample, when going on vacation, a manager might
use such functionality to have an assistant take over
some of his daily correspondence. Such alias management
functions have the potential to considerably
simplify login account and e-mail management
in big intranets. We note that to achieve this po-
tential, state has to be added to the proxy design,
which goes beyond the scope of this paper.
5.1 Applications
Web browsing. There is a growing number of
web-sites that allow, or require, users to establish
an account (via a username and password) before
accessing the information stored on that site. This
allows the web-site to maintain a user's personal
preferences and profiles and to offer personalized
service. The Lucent Personalized Web Assistant is
an intermediary Web proxy, which uses a Janus engine
to translate a user's information (user's e-mail
and passphrase) into an alias (username, password,
email) for each web-site. Moreover, this alias is
also used by the web-site to send e-mail back to
a user. More details of this work can be found
in [GGMM97] and at http://lpwa.com:8000/. The
intended configuration for this project is the gateway
approach of Figure 1. We note that such
concrete applications typically execute in conjunction
with many other mechanisms. For instance,
Web browsing based on the HTTP protocol in-
terfaces, among others, with SSL for encrypting
the communication and with Java and JavaScript
for downloadable executables. Each such interface
can potentially undermine the pseudonymity
of the client-server interaction. In the case of SSL,
the proxy can spoof SSL on behalf of the internal
client (see [SSL-FAQ]). The proxy can initiate
SSL between itself and other servers and thus
maintain the client's pseudonymity. Both Java applets
and JavaScript scripts, when downloaded from
a server by a client, can potentially obtain compromising
client information. Research is being conducted
which might lead to include customizable security
policies into these languages (see [GMPS97,
AM98]). A client can then choose a policy strict
enough to preserve his/her pseudonymity. Another
approach is to bundle an LPWA proxy with
an applet/script blocking proxy, as described, e.g.,
in [MRR97]. In summary, it is necessary to consider
all possible interfaces, and offer encompassing
solutions to clients.
Authenticated Web-traffic. Consider a Web
site which offers repeated authenticated personalized
stock quotes to each of its subscribers. The value
of a single transaction (e.g., delivery of a web-page
with a customized set of quotes) does not warrant
the cost of executing a handshake and key distribution
protocol. A lightweight security framework for
extended relationships between clients and servers
was recently proposed [MMS97]. The Janus engine
provides a persistent client-side generated shared
key for each server, used in application-layer primi-
tives. Hence, no long-term secure memory is needed
on the client-side, enabling scalability and mobility.

Acknowledgments

We thank David M. Kristol for his insights and for
his many contributions to the design implementation
of LPWA, which uses the Janus engine. We
are grateful to Russell Brand for thought-provoking
discussions.



--R

The classification of hash func- tions
Security of Web Browser Scripting Languagea: Vulnerabilities
The Anonymizer.
FAQ, http://wwww.
The security of cipher block chaining
Untraceable Electronic Mail
Transaction systems to make big brother obso- lete
The block cipher SQUARE
Anonymity and Privacy on the Internet.
How to make personalized Web browsing simple

Mixing email with ba- bel




Blocking Java Applets at the Firewall

Networks without user observability - design options
P3P Architecture Working Group
The RC5 encryption algorithm
Crowds: Anonymous Web Transactions.
Springer Verlag LNCS 1109
IEEE Symposium on Security and Privacy

--TR
transaction systems to make big brother obsolete
Networks without user observabilityMYAMPERSANDmdash;design options
Crowds
Onion routing
Consistent, yet anonymous, Web access with LPWA
The platform for privacy preferences
Untraceable electronic mail, return addresses, and digital pseudonyms
The Security of Cipher Block Chaining
MDx-MAC and Building Fast MACs from Hash Functions
Anonymous Communication and Anonymous Cash
How to Make Personalized Web Browising Simple, Secure, and Anonymous
Privacy-enhancing technologies for the Internet
Mixing Email with Babel
Blocking Java Applets at the Firewall

--CTR
Robert M. Arlein , Ben Jai , Markus Jakobsson , Fabian Monrose , Michael K. Reiter, Privacy-preserving global customization, Proceedings of the 2nd ACM conference on Electronic commerce, p.176-184, October 17-20, 2000, Minneapolis, Minnesota, United States
Blake Ross , Collin Jackson , Nick Miyake , Dan Boneh , John C. Mitchell, Stronger password authentication using browser extensions, Proceedings of the 14th conference on USENIX Security Symposium, p.2-2, July 31-August 05, 2005, Baltimore, MD
Jasmine Novak , Prabhakar Raghavan , Andrew Tomkins, Anti-aliasing on the web, Proceedings of the 13th international conference on World Wide Web, May 17-20, 2004, New York, NY, USA
Stuart G. Stubblebine , Paul F. Syverson , David M. Goldschlag, Unlinkable serial transactions: protocols and applications, ACM Transactions on Information and System Security (TISSEC), v.2 n.4, p.354-389, Nov. 1999
privacy;pseudonym;persistent relationship;janus function;mailbox;anonymity