Note: Descriptions are shown in the official language in which they were submitted.
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
BI-DIRECTIONAL, ANONYMOUS ELECTRONIC
TRANSACTIONS
Field of the Invention
The present invention relates to the field of computer systems. In particular,
a system
and methods are provided for processing bi-directional, anonymous transactions
in such a
manner as to protect a user's confidential identity.
Background of the Invention
As computer systems become increasingly interconnected, the number of
electronic
transactions between distributed users grows commensurately. Electronic mail
remains one of
the most common types of transaction conducted between users, but other
transactions are
proliferating as well. In particular, electronic commerce has increased as
methods of providing
secure transactions have been developed.
Cryptographic security schemes that employ symmetric keys, such as Digital
Encryption Standard (DES), are sometimes used to protect electronic
communications,
including electronic mail. With symmetric keys, the same key used to encrypt a
message is
used to decrypt it as well. Public key encryption (PKE) security schemes, such
as RSA (named
for its inventors: Rivest, Shamir and Adleman) by RSA Security, Inc., have
also been
developed. PKE schemes employ asymmetric key pairs wherein information
encrypted with
one key is decrypted with its complement. With PKE, communications between one
entity and
one or more other entities are secured by keeping one key "private" (i.e.,
known only to the
single entity) while making the complementary key "public" (e.g., distributed
among the other
entities).
In addition to providing adequate security regarding the content and details
of electronic
transactions, there axe a number of other features that are desired in systems
for processing
such transactions. Desirable features include authenticating a party's
identity (i.e., ensuring
that the party is who he or she claims to be), preventing repudiation of the
transaction (i.e.,
preventing a party from disavowing his or her participation) and ensuring the
integrity of the
transaction (e.g., ensuring that a party can determine if the details or
content have been altered).
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
Iri addition, demand is growing for the ability to transmit electronic
communications and
conduct electronic transactions in which one or more of the involved parties
are anonymous or
pseudo-anonymous.
Previous attempts to create a suitable environment for conducting electronic
S transactions have been unsuccessful in providing all of these features. In
particular, those
systems attempting to provide some form of anonymity have generally sacrificed
some level of
non-repudiation, authentication, or validity. In general, known systems
provide less than
satisfactory anonymity for users' confidential information or identities
(e.g., name, address,
financial data). For example, Pretty Good Privacy (PGP), a known scheme for
protecting
message contents, offers a fairly high level of authentication, validity, and
non-repudiation, but
provides no anonymity. An Internet service known by the Uniform Resource
Locator (LTRL) of
http://www.anonymizer.com provides anonymity between users and web sites, but
the service
remains aware of the users' confidential identities, thus falling short of
true anonymity. In
addition, this service is capable of providing anonymous electronic mail in
only one direction
(i.e., from users employing the service).
One system that provides a modicum of non-repudiation and anonymity is
provided by
DigiCash, Inc. Both parties involved in a DigiCash transaction (e.g., a
merchant system and a
consumer system), however, must be specifically configured to support the
transaction
protocol. Illustratively, the consumer system purchases DigiCash and tenders
it to a merchant
system. The merchant system must then trade it for more traditional currency.
The DigiCash
system does not, therefore, make existing forms of payment (e.g., credit
cards) anonymous on
either end of a transaction.
In addition, electronic transaction systems such as those described above are
tailored to
individual types of transactions (e.g., sending electronic mail, disbursing
digital currency,
submitting a news posting). A system providing the identified features bi-
directionally (e.g., to
and from an anonymous user) in a generally applicable system (i.e., multiple
types of electronic
transactions) is unknown.
Thus, there exists in the art a need for a system for securely conducting an
electronic
transaction or engaging in electronic communication while providing anonymity
or pseudo-
anonymity for a user's co~dential identity. In such a system, a user is
(pseudo-)anonymous
not only to third parties, but to the system as well. In addition, such a
system preferably makes
the user anonymous or pseudo-anonymous regardless of the direction of the
communication or
2
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
transaction (i.e., from or to the user). There also exists a need for method
of operating such a
system to perform multiple types of electronic transactions.
SUMMARY
In an exemplary embodiment of the invention, a system and methods are provided
for
exchanging bi-directional, pseudo-anonymous communications between a user and
a third
party. In this embodiment, the user is given pseudo-anonymity in order to mask
his or her
selected confidential identity (e.g., the user's true name, address or
financial data), which
confidential identity would otherwise identify the user in some manner. A
pseudonym is
provided for use in place of the confidential identity, such that transactions
are performed for
the user under cover of the pseudonym.
Thus, in this embodiment of the invention a communication directed from the
user to a
third party is received at an electronic intermediary. The electronic
intermediary also receives a
digital certificate from the user and authenticates the user by
cryptographically verifying the
certificate.
The pseudo-anonymous communication is then cryptographically signed with an
asymmetric key associated with the user's pseudonym and the signed
communication is
transmitted to the third party. Although the third party is prevented from
learning the user's
confidential identity from the communication, the third party can authenticate
the pseudonym
using a cryptographic method.
In another embodiment of the invention, a pseudo-anonymous account is created
on the
intermediary for the user before he or she can conduct pseudo-anonymous
transactions. In this
embodiment, the user's true identity (e.g., the confidential identity that is
masked by the user's
pseudonym) is verified. Then, a second digital certificate, including a
digital certificate of the
intermediary, is generated and associated with the pseudonym. This second
digital certificate is
used by third parties to cryptographically verify the user's pseudonym after
receiving a
communication in the name of the pseudonym.
These and other embodiments of the invention v~~ill be described in greater
detail with
respect to the figures and description below.
3
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
DESCRIPTION OF THE FIGURES
FIG. 1 is a block diagram depicting a system for bi-directional, anonymous
electronic
transactions in accordance with one embodiment of the present invention.
FIG. 2 is a flow chart demonstrating a method of registering a new anonymous
user
account in accordance with an embodiment of the present invention.
FIGs. 3A-3B are flow charts depicting a method of establishing an anonymous
user
session in accordance with an embodiment of the present invention.
FIGs. 4A-4C are flow charts depicting a method of sending an electronic mail
message
from an anonymous user in accordance with an embodiment of the present
invention.
FIG. 5 is a flow chart depicting a method of receiving a message for an
anonymous user
in accordance with an embodiment of the present invention.
FIG. 6 is a flow chart depicting a method of retrieving an anonymous user's
electronic
mail messages in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
The following description is presented to enable any person skilled in the art
to make
and use the invention, and is provided in the context of a particular
application and its
requirements. Various modifications to the disclosed embodiments will be
readily apparent to
those skilled in the art, and the general principles defined herein may be
applied to other
embodiments and applications without departing from the spirit and scope of
the present
invention. Thus, the present invention is not intended to be limited to the
embodiments shown,
but is to be accorded the widest scope consistent with the principles and
features disclosed
herein.
For example, although one embodiment of the invention described below provides
a
user with "name anonymity" wherein the protected confidential identity is the
user's true name,
the present invention is not limited to protecting a particular form of
confidential identity.
Other confidential identities may also be protected, such as the user's
address, financial data
(e.g., credit card number, bank account number) and the like. A user's
pseudonym serves to
protect whichever confidential identity she specifies.
A user's pseudonym may also correspond to various types of information. In one
embodiment of the invention, a fictitious or otherwise false name, generated
randomly or
arbitrarily, is employed as a user's pseudonym. Other possibilities include
the user's address or
4
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
electronic mail address. In addition, when the confidential identity to be
protected comprises
information other than the user's true name, his or her true name may be used
as the
pseudonym. One of ordinary skill in the art will thus recognize that a user's
pseudonym may
constitute virtually any information, other than the confidential identity of
the user, and that the
confidential identity that is protected need not be the user's true name.
Thus, in alternative embodiments of the invention various types of anonymity
or
pseudo-anonymity are provided, an illustrative sampling of which follows. When
"address
anonymity" is desired, a user's street address is protected by using, for
example, her true name
as her pseudonym. When a user requires "financial anonymity" (or "billing
anonymity"), her
credit card number or other confidential financial identity is secured by
applying her true name
or address as her pseudonym. In "physical anonymity," a user's physical
mailing address can
be masked with her email address. With "total anonymity," multiple
confidential identities of a
user (e.g., true name, true address, financial data) are screened by a
pseudonym that is random
or arbitrary.
1 S Due to the various types of anonymity or pseudo-anonymity provided for a
user in the
myriad possible embodiments of the present invention, the terms "anonymous"
and
"anonymity" as they appear below should be understood to be interchangeable
with "pseudo-
anonymous" and "pseudo-anonymity." More generally, pseudo-anonymity should be
understood to cover a range of degrees of anonymity, from minimally anonymous
to truly
anonymous.
Description of One Embodiment of the Invention
FIG. 1 depicts one embodiment of the invention in which a system and method
are
provided for bi-directional electronic communications conducted on behalf of a
pseudo-
anonymous party. System 100 allows a user to conduct electronic communications
(e.g.,
electronic mail, commerce, banking, electronic transactions, and orders for
physical
transactions, goods or services) with third parties without the third parties
learning a
confidential identity (e.g., name, street or physical address, electronic mail
address, IP address,
financial identifier) of the user. A user is provided with a pseudo-anonymous
identity, such as
a pseudonym, to mask his or her confidential identity. Illustratively, a
pseudonym takes the
form of a non-confidential, but limited, identity of the user (e.g., where a
user's confidential
identity comprises his address, his pseudonym illustratively comprises his
name).
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
Alternatively, however, a user's pseudonym comprises a random or arbitrary
name, number or
other alphanumeric sequence.
In normal operation of system 100 the user's confidential identity is unknown
even
within the system. However, as described below, should the user's transactions
or other
communications become subject to review or monitoring by a legally authorized
entity (e.g., in
response to a court order), the user's activities are processed in a "monitor"
mode of operation
in which the user's communications are captured or recorded. Illustratively,
however, the
user's activities performed prior to or subsequent to the period of monitoring
are not
compromised or revealed. In a present embodiment of the invention, during the
monitor mode
of operation the cryptographic keys employed to secure the user's
communications are not
revealed even though the contents of the communications are made available to
the authorized
entity.
With reference now to FIG. 1, system 100 is configured to provide anonymity to
a user
whose confidential identity comprises his name and whose pseudonym comprises
an arbitrary
or random name (e.g., Anonymous123). Those skilled in the art will, however,
appreciate that
virtually any other combination of pseudonym and confidential identity could
be used. The
user employs client 102 to access system 100. Client 102 is illustratively a
web browser, a
browser plug-in, a Java applet, an application patch, or a software program.
Client 102 may be
provided by the operator of system 100. Client 102 operates on the user's
behalf in
transactions processed by system 100. As discussed below, during a normal mode
of operation
of the illustrated embodiment, client 102 is the only element that is aware of
both the user's
pseudo-anonymous and confidential identities. In a "monitor" mode of operation
(discussed in
a subsequent section below), however, the confidential identity is stored in a
secure form on
system 100.
Mask module 104 is an interface between system 100 and client 102 in the
illustrated
embodiment of the invention. Mask module 104 masks characteristics of the
user's
confidential identity from third parties and the remainder of system 100.
Although mask
module 104 may learn the IP address of client 102, it does not have access to
the user's
pseudonym or the content of the user's transactions. As discussed below, mask
module 104
generates a unique session identifier each time a user connects to system 100
to conduct a
transaction. Illustratively, the session identifier is used to identify a
particular user's
communications with and/or within system 100 in place of information that may
compromise
6
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
the-user's anonymity. Thus, in the illustrated embodiment of the invention,
the unique session
identifier is used by mask module 104 and one or more other components of
system 100 to
identify a user's session while maintaining the user's anonymity.
Coordination module 106 coordinates the processing of anonymous communications
through and within system 100. In particular, coordination module 106 manages
a user's
anonymous communications by coordinating and submitting relevant portions of
each
communication to one or more operating modules (e.g., billing module 108,
account module
110 and action modules 112, 114, 116). Coordination module 106 helps ensure
that each
operating module is able to perform its portion of a user's transaction while
remaining ignorant
of other details of the transaction. Illustratively, each operating module
receives from
coordination module 106 only the information necessary to perform its portion
of the user's
transaction. As discussed in a subsequent section, in the "monitor" mode of
operation
coordination module 106 records or logs information concerning the content of
transactions
conducted by a monitored user. In a normal mode of operation, however, the
details of
anonymous transactions are unavailable to coordination module 106.
As discussed above, to protect a user's anonynuty within system 100, a unique
session
identifier is used to identify each user session. In the illustrated
embodiment, however, a
unique identifier generated by mask module 104 is, within system 100, only
used for
communications between mask module 104 and coordination module 106. In this
embodiment, coordination module 106 generates separate, unique, identifiers
for each
communication it passes to an operating module, and vice versa. Thus, every
communication
exchanged between the coordination module and an operating module has a
different identifier
(illustratively generated by the sender). One of ordinary skill in the art
will recognize that by
associating different identifiers with different portions of a user's
communication or
transaction it becomes more difficult to associate any one communication or
transaction with a
particular user. It also becomes more difficult for an intruder to piece
together the myriad
pieces of one communication or transaction.
System 100 interfaces with third parties through the operating modules in
order to
perform transactions and other communications on behalf of anonymous users,
using their
pseudonyms. Third parties include recipients and/or initiators of
communications involving a
user served by system 100. Illustrative third parties thus include, but are
not limited to,
electronic mail correspondents, billing parties, financial entities and
electronic entities (e.g.,
7
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
web servers, Internet application servers). For purposes of the present
invention,
"communication" is understood to broadly encompass numerous types of
information and data,
regardless of form (e.g., graphical, numerical, audio) or method of encoding,
and "transaction"
is understood to include any transaction facilitated by such communication.
Billing module 108 illustratively performs activities necessary to bill the
user for his or
her activity, and thus connects to third party billing authorities (e.g.,
credit card issuers, digital
cash authorities, value acquirers).
Account module 110 maintains account information for users based upon their
pseudonyms (i.e., their pseudo-anonymous identities). Account information
maintained on
account module 110 includes the actions or types of transactions a user is
authorized to conduct
using system 100. Different types of accounts are created for different users
based upon the
transactions they wish to conduct; the type of account illustratively
determines the permitted
functions. Also, an indicator is stored with each user account to reflect
whether the associated
user is to be monitored (via the "monitor" mode of operation described in
detail in the
following section). In addition, account module 110 may act as an enhanced
Certificate
Authority (CA) for system 100. In its role as CA in one embodiment of the
invention, account
module 110 generates two digital certificates for each user, as discussed
below.
Finally, system 100 may include one or more action modules among its operating
modules. In an exemplary embodiment of the invention, action modules interface
with third
parties to deliver or exchange information or to perform operations on behalf
of pseudo-
anonymous users (e.g., by employing the user's pseudonym in place of his or
her confidential
identity). Illustrative services or functions offered by action modules
include, without
limitation: sending electronic mail, receiving electronic mail, browsing web
sites and pages,
posting news messages, conducting electronic commerce, participating in an
Internet
conversation (e.g., "chatting"), etc. Each action module is thus configured
according to a
specified function or role. For example, an electronic commerce action module
must be
conversant in commerce protocols while electronic mail action modules must
understand
various mail protocols. The functions and characteristics of exemplary action
modules are
well-known to those skilled in the art and need not be described in detail
here.
The scope of the present invention is not limited to a particular quantity of
action (or
other operating) modules, or to particular functions performed by the various
modules.
Illustratively, however, each operating module receives only the information
necessary to
8
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
perform its function and the information passed between the user and each
operating module is
encrypted and is thus inaccessible to either mask module 104 or coordination
module 106
(except in the monitor mode of operation). For security purposes, then, in
system 100 every
module could maintain a memory area that is inaccessible to the other modules.
Each
S module's memory illustratively comprises solid-state memory devices. In an
embodiment in
which the modules share a large memory device, software means are employed to
prevent
access to other modules' memory areas. In alternative embodiments of the
invention, the
modules' memory includes software constructs (e.g., data structures such as
arrays, heaps,
queues), electronic storage media (e.g., magnetic disk, optical disk, tape,
compact disc), and
still other memory elements known to those skilled in the art.
FIG. 1 depicts an embodiment of the invention in which each module (i.e.,
client, mask,
coordination, billing, account and action modules) is nominally separated from
each other.
This nominal separation amounts to geographical separation (i.e., each module
is distinct) in
the illustrated embodiment, wherein each module is implemented on an
individual computer
system. In one alternative to geographical separation, one or more modules
comprise logically
separable portions of a single computer system. In yet another alternative to
physical
separation of the modules, they are separated organizationally, wherein one
organization
operates one module and another organization operates a second. One of
ordinary skill in the
art will recognize that the greater the separation between client module 102
and modules within
system 100, the greater the degree to which access to user information on
client 102 or within
system 100 may be constrained.
The greater the "need-to-know" of system 100 concerning user information on
client
102, the weaker the nominal separation between client 102 and the modules of
system 100.
For example, in the monitor mode of operation discussed in the following
section, system 100
has a relatively high need-to-know. Varying degrees of overlap are thus
contemplated between
the modules in alternative embodiments of the invention. In one alternative
embodiment, one
or more of the modules within system I00 are co-located. In yet a further
alternative
embodiment, client 102 overlaps or is co-located with one or more of the
modules of system
100.
In a normal mode of operation in the embodiment of the invention depicted in
FIG. 1, a
user at client 102 registers (e.g., creates) an account with system 100 before
conducting
anonymous transactions. At the time of account registration, a pseudonym is
chosen or
9
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
assigned to the user. Illustratively, the pseudonym also serves as the user's
account name.
Following the assignment of a pseudonym, two digital certificates are created.
The first
certificate (hereinafter termed "Certl") is used to validate the user's
identity to system 100
when he or she connects to the system to conduct an anonymous transaction. In
this context,
"identity" includes the user's confidential identity (which could, of course,
include the user's
true identity). Certl therefore advantageously eliminates the need for system
100 to retain the
user's confidential identity while processing his transaction, thus
maintaining his anonymity
even within system 100. The second digital certificate (hereinafter termed
"Cert2") is used to
sign outgoing anonymous communications from the user (i.e., to imprint the
communications
with the user's pseudonym). In the presently described embodiment of the
invention, client
102 generates or otherwise issues a first pair of asymmetric (i.e.,
public/private) keys, from
which Certl is generated, and account module 110 generates or otherwise issues
the second
pair of keys, from which Cert2 is generated. The members of the first pair of
asymmetric keys
are hereafter termed PuKI and PrKI, while the members of the second pair are
termed PuK2
and PrK2.
When a registered user wishes to conduct an anonymous transaction or
communicate
anonymously with a third party, he or she again accesses system 100 through
mask module 104
and establishes a user session. The user is then authenticated (using Certl),
and public keys
corresponding to coordination module 106 and the operating modules are
downloaded to client
102. Various pieces of information provided by the user and needed by system
100 to effect
the transaction or cammunication are individually packaged and encrypted with
the public keys
of the operating modules that must act upon the information.
In one embodiment of the invention, the information necessary to conduct an
anonymous transaction is separated into packages in accordance with
instructions stored on
client 102. For an outgoing electronic mail message, for example, client 102
packages the
user's billing information (needed by billing module 108) separately from the
body of the
message (needed by action module 112 when acting as an outgoing mail server).
The
instructions illustratively allow client 102 to recognize the type of
transaction and to create the
appropriate packages.
A transaction identifier (e.g., a code identifying the type of transaction or
communication) is then combined with the packages) to form a "bundle," which
is then
encrypted with a public key of coordination module 106. Mask module 104 may
remove any
CA 02335968 2000-12-22
WO 00/01108 PC'T/US99/13908
information from bundles sent from the user to system 100 that may identify
the user's true or
confidential identity (e.g., IP address, electronic mail address) and forwards
the bundles to
coordination module 106.
Coordination module 106 decrypts each bundle to retrieve the transaction
identifier and
the individual packages of information. The packages are forwarded to the
appropriate
operating modules to conduct or process the indicated transaction. Each
operating module
illustratively receives only the information necessary to perform its discrete
task (e.g., when
sending electronic mail, billing module 108 receives the user's billing data,
but not the content
of the message or the recipient's confidential identity). Each operating
module decrypts the
packages) sent from the coordination module and performs its specified
task(s).
As stated above, in the presently described embodiment of the invention an
outgoing
communication is digitally signed by encrypting it with private key PrK2
corresponding to
public key PuK2 in the second digital certificate Cert2. The pseudo-anonymous
user's Cert2 is
passed to the recipient along with the communication in this embodiment. The
recipient may
then authenticate the certificate by contacting account module 110 in its role
as a CA. In an
alternative embodiment of the invention, the digital signature is not computed
on the
communication per se, but on a message digest such as that created by
"hashing." In this
alternative embodiment, an outgoing communication is run through a hashing
algorithm to
produce a hash result (generally of fixed length). This result is then
encrypted with the
originating pseudo-anonymous user's PrK2 (illustratively stored on account
module 110) to
produce a message digest that is passed to the recipient along with the
communication. The
recipient decrypts the message digest using PuK2 (illustratively forwarded as
part of Cert2) and
processes the communication with the same hashing algorithm referred to above.
If the result
of the recipient's hashing algorithm matches the decrypted message digest, the
recipient can be
confident that the communication was not altered during its journey.
As described above, the presently illustrated embodiment of the invention
employs
public key encryption (PKE) methods (e.g., Diffie-Hellman, RSA, Ei Gamal) to
safeguard
information (e.g., details of anonymous communications and transactions) and
to protect users'
confidential identities. A user's confidential identity can only be retrieved
in the "monitor"
mode of operation described below. Once a pseudonym is chosen for a user and
appropriate
digital certificates are issued, the pseudonym is used to send and receive
information to and
from third parties.
11
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
In addition to the asymmetric keys associated with Certl and Cert2, in a
present
embodiment of the invention a symmetric (e.g., DES, RC4 by RSA) key may be
used to
encrypt a user's confidential (and/or true) identity, which is then stored on
system 100. The
symmetric key is illustratively retained on client 102 and is inaccessible to
system 100 unless
and until retrieved in accordance with the "monitor" mode of operation, in
which case the key
is retrieved and the user's identity decrypted and provided to an authorized
entity. In an
alternative embodiment of the invention, a symmetric key is used to encrypt
and decrypt
communications between client 102 and system 100 before Certl is issued.
One skilled in the art will thus appreciate that various methods and types of
cryptographic security may be utilized within the scope of the invention.
Monitor Mode of Oueration
In connection with the above-described embodiment of the invention, a
"monitor"
mode of operation may also be provided. While operating in this mode, system
100 may
satisfy legal or other requirements of an entity authorized to retrieve the
content of
communications to and/or from a particular user (e.g., based upon the user's
pseudonym or
account name). When system 100 is placed in the monitor mode of operation for
a particular
user (e.g., in response to a court order), account module 110 stores an
indicator (e.g., a flag or
database entry) with or within the specified account, illustratively based on
a pseudonym or
account name provided by the entity.
As introduced above, in this embodiment the user's confidential identity
(which could
include the user's true identity), is stored on account module 110 in
encrypted form (e.g., from
the time of account creation). The confidential and/or true identities are
encrypted with a
symmetric key (e.g., as provided by DES) that is maintained only on client
102. When monitor
mode is turned on in this embodiment, the key is retrieved from client 102 and
the user's
confidential and/or true identities are decrypted and provided to the entity
(preferably, but not
necessarily, being encrypted or otherwise secured prior to transmission to the
entity).
In the event that a user's confidential identity must be recovered (e.g.,
because monitor
mode is activated) but the user never re-connects to system 100, the encrypted
identity or
identities may still be provided to the monitoring entity. Although system 100
will not be able
to decrypt or provide the decryption key for this information in the presently
described
12
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
embodiment, the monitoring entity may possess the resources to overcome the
cryptographic
security and retrieve the desired information.
As was described in the previous section, the content of a user's
communications are
normally kept secure by encrypting portions of the content with public keys of
one or more
modules of system 100. In monitor mode, however, the content of the user's
communications
must be provided to the authorized entity. Advantageously, though, the entity
is not given the
modules' private keys in the presently described embodiment. Instead, system
100 (e.g., via
coordination module 106) decrypts and records the user's communications and
provides the
content to the authorities. In order to make this possible, client 102
illustratively is sent, in
place of the valid public keys of the operating modules that would be sent in
a normal mode of
operation, multiple copies of a public key of coordination module 106. Thus,
when the user's
information packages are encrypted by client 102, they are encrypted using the
coordination
module's key. When a bundle is received by coordination module 106 for
dissemination to the
operating modules, it is thus able to decrypt and record the contents of each
package within the
bundle. After recording the contents, they are re-encrypted with valid public
keys of the
operating modules (which were illustratively stored on coordination module
106) and the
communication is thereafter handled normally.
Sometime after the details of the user's transaction are retrieved and
recorded, they are
passed to the authorized entity. In one embodiment of the invention, a
separate public/private
key pair may be generated to secure the details for transmission to the
entity. Illustratively,
coordination module 106 (or account module 110) generates the key pair. The
private key is
provided to the entity via some appropriately secure means (e.g., by hand, via
Diffie-Hellman
or other well-known key exchange protocols, by encryption with a second key)
while the public
key is retained by coordination module 106. The public key is then used to
encrypt the details
before they are sent to the entity, at which point the private key is used to
retrieve them.
In one alternative embodiment of the invention, coordination module 106 avoids
the
possibility that a user or client 102 may observe the receipt of multiple
identical keys, as
described above, and thereby detect the activation of monitor mode.
Specifically, for monitor
mode operation in this alternative embodiment, coordination module 106 (or,
for example,
account module 110) generates a separate pair of public and private keys for
each operating
module for which client 102 is to receive a key. The public keys are then
delivered to the client
and the private keys are retained by coordination module 106 in order to
access the contents of
13
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
theuser's communications and transactions. Because the client receives
different keys for each
operating module, the activation of monitor mode is further concealed.
One of ordinary skill in the art will understand that cryptographic security
of user's
communications and transactions is thus ensured, on the one hand, by
separately encrypting
different portions of a user's communication or transaction. However, the
cryptographic
security can be breached, on the other hand, by providing a substitute for the
operating
modules' public keys, the complements (i.e., the corresponding private keys)
of which are
retained on system 100. The substitute may, of course, be substituted for less
than all of the
operating modules' keys, in which case certain information (e.g., billing
data) will not be
recovered.
In an alternative embodiment of the invention the user's confidential and/or
true
identities are encrypted with a public key of system 100, or one of its
constituent modules, and
stored on system 100 (preferably in a module other than the one whose key was
used to encrypt
the identities). When monitor mode is turned on, the encrypted identities are
retrieved and
decrypted using the corresponding private key. They may then be encrypted
using a key
specified by the monitoring entity before being delivered to the entity (e.g.,
account module
110 generates a separate pair of keys for securing communications between
system 100 and the
monitoring entity).
In another alternative embodiment, when the user next establishes a session
with system
100 after monitor mode is activated, his or her confidential and/or true
identities are retrieved
from client 102. Illustratively, the identities are encrypted with a symmetric
key or a public key
of system 100 (or one of its modules) before being transmitted to system 100
from client 102.
Creating an Anonymous User Account
Before a user can send and receive anonymous communications through system
100, an
account must be created to register the user and provide him or her a
pseudonym. It is during
this registration process that the two key pairs and digital certificates
mentioned above are
generated or otherwise obtained. An illustrative method of registering a user
and establishing a
pseudonym is described below with reference to FIG. 2. Briefly, however, the
process may be
summarized as follows.
A user at client i 02 logs into system 100 through mask module 104 and chooses
the
type of account he wishes to establish. Depending upon the type of account
chosen, the user's
14
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
true identity, or at least the confidential identity that is to be protected,
is validated with a
commensurate degree of confidence. If the user desires a highly trusted
account with which to
conduct electronic commerce, for example, his identity must be established
with certainty in
order to eliminate the danger of impersonation. After the user's identity
(true and/or
confidential) is verified, he chooses a pseudonym (e.g., a fictitious name)
for his account.
Mask module 104 communicates with account module 110 (through coordination
module I06)
to determine whether the desired pseudonym is already in use. Once a unique
pseudonym is
chosen (e.g., Anonymous123), client 102 generates via standard techniques
known to those
skilled in the art, or otherwise obtains (e.g., from a key issuer), a first
pair of keys. The first
private key ( "PrKl ") is retained on client 102 and the first public key (
"PuKl") is delivered to
account module 110. Pukl is signed by system 100 to generate a first digital
certificate
("Certl"), which is then returned to client 102.
. Account module I 10 then generates or obtains a second pair of keys. The
second
private key ("PrK2") is stored on account module 110 and the second public key
("PuK2") and
1 S the user's pseudonym are signed with the system's private key to generate
a second digital
certificate ("Cert2"). Cert2 is also stored in account module 110.
The user is now registered and can send and receive anonymous communications
and
conduct pseudo-anonymous transactions through system 100. Certl is used to
validate the user
to system 100 whenever he wishes to establish a user session and use the
system, and Cert2 is
used to assert the user's anonymous identity (i.e., his pseudonym) to third
parties and to receive
communications sent to the user in his pseudo-anonymous identity.
With reference now to FIG. 2, an illustrative detailed description of this
procedure is
presented. State 200 is a start state. In state 202, a user at client 102
connects to, or logs into,
mask module 104. In one embodiment of the invention client 102 is a web
browser and state
202 involves the user accessing a web page corresponding to system 100. In an
alternative
embodiment, client 102 comprises a series of executable instructions provided
by the operator
of system 100, in which case the user simply operates the client software as
instructed.
After connecting to mask module 104, in state 204 the user initiates the
account
creation process. Illustratively, this is accomplished by selecting a
corresponding option from a
list of functions or operations offered by system 100. In an alternative
embodiment in which
client 102 comprises software provided by the producer of system 100, the
user's initial
connection to mask module 104 automatically initiates the account creation
process.
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
- The user then, in state 206, chooses the type of account he desires. In a
present
embodiment of the invention, two types are possible: Type 1 and Type 2.
Illustratively, a Type
1 account limits the associated user to basic anonymous transactions (e.g.,
those requiring a
relatively low level of user authentication) such as electronic mail or web
browsing. With a
Type 2 account, the user may perform additional functions, such as electronic
commerce. The
type of account chosen by the user determines how thoroughly the user's
identity (confidential
and/or true) is validated. One skilled in the art will recognize that
additional types of accounts
may be provided in alternative embodiments of the invention or that the
invention may even be
limited to a single type of account.
In the presently described embodiment of the invention, if the user chooses a
Type 1
account the account creation process jumps to state 210 below. In an
alternative embodiment,
the system will first verify (e.g., by querying the user), that the user is
the only person with
access to the electronic mail account that the user will use to send and
received electronic mail
using his pseudonym. In other words, because a Type 1 account is, in this
embodiment of the
invention, limited to sending and receiving electronic mail, it is sufficient
to ensure that only
the one user has access to the electronic mail account. This assurance is
necessary in order to
prevent the user from repudiating electronic mail sent from his account. In
another alternative
embodiment, the system simply contacts an identification server to verify an
electronic mail
account identified by the user (e.g., by invoking the verify command of a
computer system's
sendmail daemon).
Type 2 accounts allow additional types of anonymous transactions (e.g.,
electronic
commerce). Therefore, it is not enough to ensure that the user is the only
person accessing the
user's account. If the user chooses a Type 2 account, system 100 ensures in
state 208 that the
user establishing the account is the person that he says he is. If the user's
true identity were not
validated, a dishonest person could create an anonymous account in the name of
another person
and make purchases in that other person's name, thus defrauding merchants and
subjecting that
person to unwarranted legal and financial disputes. in a present embodiment of
the invention
the user's true identity is authenticated by requiring a Class 2 digital
certificate issued by
VeriSign, Inc. or a comparable certificate from another trusted CA. The user
transmits his
authenticating certificate to system 100, where it can be validated in
cooperation with the
issuing CA. In an alternative embodiment, state 208 involves an alternate
method of validating
the user's true identity. Possible methods include, but are not limited to:
requiring a user to
16
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
register an account in person, retrieving and examining a credit report,
verifying a national
identification card, using a biometric device (e.g., fingerprinting, retinal
scan), or any other
suitable method that may be developed.
Then, in state 210, the user selects a pseudonym. In the presently described
embodiment, the pseudonym takes the form of an arbitrary or random name or
other
alphanumeric sequence and is also used as the user's account name. In an
alternative
embodiment, the pseudonym comprises some identifying information (e.g.,
electronic mail
address) of the user other than his or her confidential identity.
Illustratively, the user is
prevented from choosing an offensive or otherwise inappropriate name. In
addition, the user is
prevented from choosing a pseudonym that may generate confusion concerning
another person
or entity. Alternatively, system 100 assigns the user a pseudonym instead of
allowing the user
to choose his or her own. In state 212 the chosen name is submitted to account
module 110 for
validation. In state 214 the account module consults a list (e.g., a database)
of existing
pseudonyms to determine if the user's choice is already in use. If the desired
pseudonym is in
use, the user is informed and the procedure returns to state 210. Otherwise,
the procedure
proceeds to state 216.
When a valid (e.g., unique) pseudonym is chosen or assigned, it is stored in
memory on
account module 110. Various types of memory are suitable for storing
pseudonyms, including
software constructs (e.g., list, table, array), storage media (e.g., disk,
tape, compact disc) or
solid-state memory. In the presently described embodiment of the invention,
the pseudonym is
used as an account name for the newly created account. In an alternative
embodiment,
however, a separate account name is assigned.
In state 216, client 102 generates a first pair of keys (one private key and
one public
key) in accordance with public key cryptography methods. In the presently
described
embodiment, client 102 includes the ability to generate key pairs. In an
alternative
embodiment, client 102 accesses a separate key generation utility or module to
generate the
keys. The first private key (PrK 1 ) is retained by client 102
(illustratively, by being encrypted
and stored on a storage device employed by the user). The first public key
(PuKI) is, in state
218, transmitted by client 102 to mask module 104 and from mask module 104 is
transmitted
through coordinator 106 to account module 110. Additional data may be provided
as well
(e.g., user's date of birth, sex, geographical region of user's residence}. In
one embodiment of
the invention, the additional information is incorporated in one or both of
Cert1 and Cert2.
17
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
Account module 110, in state 220, digitally signs PuKl and the user's
pseudonym.
Account module 110 thus creates a first digital certificate (Certl) that will
be provided by the
user whenever he connects to system 100 to send or receive communications or
to conduct
transactions. Illustratively, the key with which Certl is signed is a private
key representing
system 100.
In state 222, Certl is returned to client 102 (through coordination module 106
and mask
module 104) where it is stored with appropriate security. In an embodiment in
which client
102 comprises software provided by the producer of system 100, Certl and PrKl
are stored in
encrypted form and the user is required to provide a password or other means
of authentication
(e.g., fingerprint) to access and use either.
Account module 110 then, in state 224, creates a second pair of keys in
accordance with
public key cryptography. In state 226, the second private key (PrK2), which is
used to digitally
sign outgoing communications in one embodiment of the invention, is stored on
account
module 110. In state 228, the second public key (PuK2), along with the user's
pseudonym and
any additional data that may have been sent from client 102 (in state 218), is
signed by system
100 to create a second digital certificate (Cert2). In one embodiment of the
invention, Puk2 is
provided (e.g., as part of Cert2) to a third party along with the anonymous
user's
communication so that the third party can validate the digital signature.
Cert2 is then
associated with the user's pseudonym and stored on account module 110 in step
230. The
procedure then ends at state 232.
In the embodiment described above, Cert2 is issued at the time of account
creation for
use in all subsequent transactions with third parties on the user's behalf In
an alternative
embodiment, Cert2 is dynamically generated when needed instead of being stored
on account
module 110. In this embodiment, PuK2 is consistently used to generate Cert2,
but other
information is included as needed. For example, in one transaction Cert2 could
include the
anonymous user's birth date. In another transaction, Cert2 could include other
personal
information, such as a geographic region in which the user resides.
In another alternative embodiment of the invention, only one pair of keys is
generated
during the account creation process (e.g., Certl and Cert2 are identical).
This alternative
embodiment provides a level of convenience but may sacrifice a portion of the
user's
anonymity (e.g., his IP address).
18
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
- Once his account is created, the anonymous user simply connects to system
100, as
needed, to establish a user session and conduct his or her anonymous
transaction(s). One
method of using system 100, as depicted in FIG. 1, to establish a user session
and send an
electronic mail message is depicted in the flow charts of FIGS. 3A-3B and 4A-
4C.
Establishing a User Session to Conduct an Anonymous Transaction
FIGs. 3A-3B demonstrate an illustrative procedure by which an anonymous user
having
an account on system 100 establishes a user session in preparation for
conducting an electronic
transaction. In summary, before a transaction can be performed, the user must
be
authenticated. Illustratively, client 102 submits Certl (the first digital
certificate created and
described above) to the system. If Cert 1 is deemed valid and the user's
account has not been
deactivated (e.g., for non-payment of a debt), the user receives one or more
"operating module
keys." Each operating module key is illustratively a public key associated
with an operating
module (e.g., billing module 10$, action module 112). The user also receives a
public key for
coordination module 106.
The use of different operating module keys ensures greater security for user
communications and transactions, in that no single module is able to determine
the user's
confidential identity or the full content of the user's message. However, in
the monitor mode
of operation a different public key (for which the corresponding private key
is retained on
system 100) is substituted for each operating module's actual key, thus
breaching this security
scheme so that communication contents can be provided to an authorized entity.
As explained
above, the substituted keys are illustratively generated by coordination
module 106 and are
different for each operating module. Alternatively, all of the substituted
keys can be identical.
In either case, the private keys) corresponding to the substituted keys are
held by coordination
module 106 in order to decrypt communication bundles and retrieve their
contents on behalf of
a monitoring entity.
With reference now to FIGs. 3A-3B, an illustrative method of establishing an
anonymous user session with system 100 is described. In the illustrated
method, state 300 is a
start state. In state 302 the user connects to, or logs into, mask module 104
using his
pseudonym (and/or his account name if different from his pseudonym). In state
304 the client
validates mask module 104; illustratively, mask module 104 passes client 102 a
digital
19
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
certificate issued by a trusted certification authority. Client 102 may
validate the certificate by
contacting the CA.
Then, in state 306 a public key of coordination module 106 is provided to
client 102.
Client 102 uses this key to encrypt bundles of transaction details or
communication content
sent to coordination module 106. As described below, individual packages of
information that,
when assembled, constitute a bundle are encrypted with public keys (e.g.,
operating module
encryption keys) corresponding to the operating modules that are to act upon
the information.
After the packages are encrypted, the entire bundle is encrypted with the
public key of
coordination module 106.
Each bundle that is encrypted with the coordination module's public key and
submitted
to coordination module 106 also includes a Transaction Type Code (TTC). The
TTC
represents the type of action the user is initiating (e.g., logging into the
system, sending an
electronic mail message, initiating an electronic purchase, retrieving
electronic mail messages),
and is retrieved by coordination module 106 by decrypting the bundle with its
private key. As
mentioned above, coordination module 106 can decrypt the bundle itself, but
packages within
the bundle (i.e., information destined for operating modules) cannot be
decrypted because they
are encrypted with the public keys of the operating modules. The corresponding
private keys
for the operating modules are held only by the individual modules.
With the coordination module's public key, in state 308 the client encrypts
Certl and a
login bundle {e.g., a bundle having a TTC corresponding to a login request).
In state 310, the
login bundle is delivered to mask module 104. Mask module 104 cannot retrieve
any portion
of the bundle but, in state 312, attaches a unique session identifier to the
bundle. Mask module
104 does not forward any information indicating the anonymous user's
confidential identity or
other identifying information (e.g., IP address, electronic mail address).
The unique session identifier that mask module 104 creates for each user
session allows
system 100 to segregate communications involving different anonymous users.
Although an
anonymous user's account name or pseudonym may be able to serve the same
purpose, one
advantage of the presently illustrated method is to provide greater anonymity
to the user within
system 100. This reduces even further the possibility of linking the user's
confidential identity
with his pseudonym. For example, if billing module 108 were provided the
user's pseudonym,
that identity could be associated with the user's billing data (e.g., credit
card number).
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
- As described above, in the presently illustrated embodiment of the
invention, the unique
session identifier generated by mask module 104 is, within system 100, only
used for
communications passing between mask module 104 and coordination module 106. In
one
embodiment of the invention coordination module 106 generates additional
identifiers for
communicating with each operating module during a user session. This scheme
further
discourages the association of a particular communication or transaction with
a particular
identity (confidential or true). In an alternative embodiment only one unique
session identifier
is generated, such as that provided by mask module 104, and is used throughout
system 100.
In state 314, the user's login bundle is delivered to coordination module 106.
The
coordination module then, in state 316, decrypts the bundle to retrieve the
TTC and Certl and
to note the session identifier. The coordination module next authenticates
Certl and verifies
the user's account in state 318 by querying account module 110. The account
module will
return an appropriate account status.
More specifically, in state 318, the account module informs coordination
module 106
that Certl is either "Invalid" or "Valid," thus indicating the status of the
user's account. In
addition to an account status, account module 110 may also return a qualifier
with the status.
In a present embodiment of the invention, two qualifiers are employed for
valid accounts:
"monitor" and "collect." The "monitor" qualifier relates to the monitor mode
of operation
discussed above, and serves to inform the coordination module that the user's
communications
are to be monitored. The "collect" qualifier indicates that the user's account
is due to be
charged some amount (e.g., for continued use of system 100).
In one embodiment of the invention, upon receipt of the "collect" qualifier
(and an
associated sum that is due) coordination module 106 instructs billing module
108 to charge the
user's credit card. Alternatively, coordination module 106 informs billing
module 108 of the
specified sum the next time a transaction is performed that involves the
billing module, in
which case the due sum is billed along with the transaction charge. In another
alternative
embodiment, coordination module 106 sends a message to client 102 to inform
the user of the
debt. Until the user returns payment information or makes other payment
arrangements,
system 100 performs no more anonymous transactions on the user's behalf
(except perhaps to
accept electronic communications from third parties - which are not delivered
until payment is
received).
21
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
In state 320, coordination module 106 receives the status information from
account
module 110. If the account is valid, the illustrated method continues at state
326. If, however,
the account is considered invalid (e.g., the account has been closed or
deleted), the
coordination module composes a message to client 102 in state 322 to inform it
(and the user)
S of this status. This message is illustratively encrypted with PuKI (from
Certl). The "invalid"
bundle is delivered to the client in state 324, after which the procedure ends
in end state 340.
In state 326, coordination module 106 elicits and receives a public key from
each
operating module (e.g., billing module 108, account module 110 and action
modules 112, 114
and 116). Advantageously, each operating module generates a new pair of keys
(i.e., one
private and one public) for each unique session identifier. Additionally, in
one embodiment of
the invention the public keys used by coordination module 106 and the
operating modules are
changed on a regular basis during a session (illustratively, new keys are
generated every hour).
Illustratively, however, old keys are valid for a limited period of time after
new ones are
generated (e.g., five minutes). Alternative mechanisms of handling the
transition between keys
are possible. For example, use of the old keys may be rejected immediately
upon generation of
the new ones, in which case client 102 may be forced to re-send information
directed to the
operating modules during the transition.
Then, in state 328, coordination module 106 determines whether monitor mode is
active for the user. As described above, this information becomes available to
coordination
module 106 during the attempted validation of the user's account. If monitor
mode is not
active, the process continues at state 334. If, however, monitor mode is
active, in state 330 the
coordination module stores the public keys received from the operating
modules. Then, in
state 332 coordination module 106 generates a new pair of public and private
keys for each
operating module that provided a public key in state 326. The private keys are
retained on
coordination module 106. In an alternative embodiment of the invention, in
state 332
coordination module 106 assembles copies of its public key to substitute for
the operating
modules' keys that were provided in state 326.
In state 334 the coordination module assembles either the operating modules'
public
keys (if monitor mode is not active) or the substitute public keys (if monitor
mode is active)
into a "success" bundle. This bundle will be returned to the client 102 to
inform the user that a
user session has been established. In an exemplary embodiment of the
invention, the keys
22
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
provided to client 102 are termed "operating module encryption keys"
regardless of whether
they constitute the operating modules' actual public keys or substitutes
therefor.
In state 336, the "success" bundle is encrypted with the user's PuKl. This
bundle can
thus only be decrypted with PrKl, the private key corresponding to PuKI, which
is stored on
client 102. In state 338, the success bundle is delivered to client 102 where
it will be decrypted
and understood to indicate that the user has been validated and that a user
session (and a unique
session identifier) has been established. The process then exits in end state
340.
It will be recalled that when monitor mode is active for an anonymous user's
account,
the contents of the user's transactions and communications are provided to an
authorized
entity. To make this possible, substitute keys were generated and provided to
client 102 in
place of the operating modules' actual keys. Therefore, instead of encrypting
information
packages for the operating modules with their actual public keys, client 102
encrypts each
package with the substitute keys. Coordination module 106 possesses the
complementary keys
for the substitutes and is thus able to easily retrieve the contents of the
user's communications,
which are then recorded or transmitted to the authorized entity.
Illustratively, the public keys
of the operating modules are stored by coordination module 106 so that the
coordination
module can encrypt the information packages before forwarding them to the
operating
modules. One of ordinary skill in the art will recognize that information
packages sent to the
operating modules after being opened by coordination module 106 are preferably
encrypted
with their own public keys in order to avoid requiring them to store
additional keys. In
addition, the scheme described above leaves the operating modules unaware that
a user's
transactions are being monitored.
In an alternative embodiment, the encrypted bundles of a monitored user, or
just the
encrypted information packages, are passed to the monitoring entity along with
the keys)
necessary to decrypt the information. In another alternative embodiment of the
invention, the
operating modules' actual public keys are provided to client 102 in state 334
regardless of
whether monitor mode is active. In this embodiment, coordination module 106
must then
retrieve the operating modules' private keys in order to decrypt the
information packages (the
contents of which are then recorded, re-encrypted and forwarded). Or, the
recording of
transaction/communication details is done by the individual operating modules.
This
alternative is relatively dissatisfactory because it requires additional time
and action on the part
of coordination module 106 and/or the operating modules.
23
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
Processing an Anonymous Transaction
FIGS. 4A-4C demonstrate an illustrative procedure for using system 100 to send
an
electronic communication from an anonymous user after a user session is
established. As
stated above, the user receives separate public keys with which to encrypt
information
packages for each operating module, thus providing each module with only the
information
necessary to conduct its role in the overall transaction. The packages are, in
the illustrated
procedure, assembled into a bundle that is encrypted with a public key of
coordination module
106. In a monitor mode of operation according to one embodiment of the
invention, however,
the public keys of the operating modules are replaced by substitute public
keys generated by the
coordination module. In an alternative embodiment, the substitute keys are
identical and
illustratively match the coordination module's public key.
The information needed to send a message is, as described above, separated
into
packages (e.g., electronic mail message, billing information) destined for
individual operating
modules. The bundle of packages is transmitted to the coordination module
where it is divided
1 S and the separate packages forwarded to the appropriate modules. In other
words, the billing
information package is submitted to the billing module, the communication or
transaction
content is submitted to an action module, etc. In the monitor mode of
operation the
coordination module decrypts and records each package of information before re-
encrypting
them (with the operating modules' valid public keys) and forwarding them to
the operating
modules. Each operating module then, under the coordination of coordination
module 106,
performs its tasks) using the provided information.
In the embodiment depicted in FIGs. 4A-4C, action module 112 is an operating
module
configured to send electronic mail. The illustrated procedure begins with
start state 400. In
state 402 the user initiates a transaction. For example, to send an electronic
mail message, after
the user composes the message he signals completion by clicking on a "send"
button or similar
icon.
Client 102 then, in state 404, encrypts the information needed to bill the
user for the
message (e.g., credit card or digital cash account number). As discussed with
reference to
FIGS. 3A-3B, client 102 received public keys ostensibly supplied by each of
the operating
modules. This information package is therefore encrypted using the key
associated with billing
module 108. However, as described previously, in a monitoring mode of
operation this key
may have been replaced with a public key of, or generated by, coordination
module 106.
24
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
- In state 406, client 102 encrypts the information (e.g., body of mail
message, recipient
identity) to be sent to action module 112 with the public key corresponding to
the action
module.
In state 408, client 102 assembles the various information packages into a
bundle and
adds a Transaction Type Code (TTC) corresponding to the function of sending
electronic mail.
Then the client encrypts the bundle in state 410 with the public key of
coordination module
106 and delivers the bundle to mask module 104 in state 412.
Next, in state 414 the mask module attaches to the bundle the session
identifier that was
generated when the user's session was established, and forwards the bundle to
coordination
module 106. The coordination module decrypts the bundle with its private key
in state 416 and
retrieves the TTC.
Based on the TTC, in state 418 the coordination module calls a transaction
handler
routine and passes it the decrypted bundle (comprised of one or more encrypted
information
packages destined for one or more operating modules). Illustratively,
coordination module 106
includes a separate transaction handler routine to coordinate each type of
transaction. Each
transaction handler is thus configured to forward information packages to the
appropriate
operating modules without decrypting them or otherwise knowing their contents
(except in the
monitor mode of operation). It will be recalled that different session
identifiers are
illustratively generated for each communication sent between coordination
module 106 and the
operating module.
Additional action must be taken if monitor mode is active for the user. In
particular, the
contents of the user's transaction must be recorded for (or directly
transmitted to) an authorized
monitoring entity.
In state 420, coordination module 106 determines whether monitor mode is
active.
Illustratively, the coordination module was provided with this information at
the time that the
user session was established. When, however, monitor mode is activated during
a user session,
the next time the operating modules' public keys are changed the coordination
module will
substitute its public key (or those it generates) for the operating modules'
keys. As described
above, coordination module 106 stores the operating modules' public keys in
monitor mode in
order to re-encrypt the information packages after recording them. In one
alternative
embodiment of the invention, when monitor mode is activated during a user
session the
operating modules are automatically prompted to issue new public keys. In
another alternative
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
embodiment, when monitor mode is activated during a user session, it does not
take effect until
the user's next session.
If monitor mode is not active, the process continues with state 426. However,
if
monitor mode is active, in state 422 coordination module 106 (e.g., the
transaction handler
routine) decrypts and logs (e.g., records) the contents of each information
package. Then, in
state 424, the coordination module (e.g., transaction handler routine) re-
encrypts each
information package using the stored public key of the operating module to
which the package
is to be delivered.
In state 426 the billing package is delivered to billing module 108, which
decrypts and
processes the billing data in state 428. While processing the billing data,
the billing module
may be required to make or use a connection to third parties such as credit
card issuers, banks,
value acquirers, etc. Illustratively, billing module 108 receives only the
information necessary
to charge the user for the transaction, which may include a portion of the
user's confidential
identity (e.g., where the confidential identity includes the user's true name,
which is necessary
for credit card billing) but does not learn the user's pseudonym.
Alternatively, billing module
108 could receive all or substantially all of the contents of the encrypted
bundle sent from
client 102. Non-billing information remains safe, however, as the billing
module normally
does not possess the keys) necessary to decrypt any information other than its
billing
information.
In state 430, the transaction handler routine determines whether the billing
data was
successfully processed. If not, an error is returned to client 102 in state
432 at which point the
process ends at end state 460.
If the billing data is successfully processed, then in state 434 the
coordination module
(e.g., the transaction handler routine) passes the action package to action
module 112. The
action module decrypts the package in state 436 and processes the action
information (e.g.,
recipient of the message, message text, sender's pseudonym). If action module
112 determines
in state 438 that the outgoing electronic mail message is complete, the
process continues at
state 448. When, however, additional information is needed (e.g., no
recipients are identified
or the message indicates that an attachment should be included but no
attachment was sent in
the package), the action module informs coordination module 106. The
coordination module
then, in state 440, sends a message to client 102 requesting the additional
information. In state
442, the additional information is encrypted with the public key associated
with action module
26
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
112 (which may, of course, be the coordination module's public key) and the
information is
delivered in state 444. Illustratively, this additional information is
transmitted in the same
manner as other information (e.g., within a package inside a bundle that is
encrypted with the
coordination module's public key and sent to the coordination module). Action
module 112
decrypts the additional information in state 446 and assembles the outgoing
message.
Action module 112 now has the complete contents of the outgoing message. The
message must, however, be digitally signed, illustratively by using Cert2
(e.g., PuK2). Thus,
the body of the outgoing message is passed to account module 110 in state 448.
In one
embodiment of the invention, the body of the message is encrypted by action
module 112 with
a public key of account module 110. The encrypted body is then passed back to
coordination
module 106 with a code (e.g., a TTC) specifying the need for a digital
signature. Coordination
module 106 then passes the message body to account module 110.
Upon receipt, account module 110 digitally signs the message in state 450 and
returns
the signed message to action module 112 in state 452 (e.g., by encrypting it
with a public key
of the action module and passing it back through the coordination module). In
one
embodiment of the invention, the message is signed by appending a message
digest to the
message (e.g., generating a hash value from the message and encrypting it with
PrK2).
In state 454, the action module determines whether a public key or digital
certificate is
available for the recipient. If not, the process continues at state 458.
Otherwise, the outgoing
message is encrypted in state 456 using the recipient's stored public key. The
outgoing
message is transmitted to the recipient in state 458. The process ends with
end state 460.
In one alternative embodiment of the invention, action module 112 maintains a
record
of recipients to whom electronic mail is not to be sent (e.g., recipients who
have requested not
to receive electronic mail sent from one or more anonymous users).
Illustratively, a global list
is maintained to identify electronic mail addressees who are not to receive
electronic mail from
any anonymous user of system 100. Individual lists are also maintained in this
embodiment for
each valid user account, as necessary, to identify the addressees that are not
to receive mail
from the individual user. The individual lists may duplicate the global list
or, alternatively,
simply include addressees not included in the global list. In this alternative
embodiment,
action module 112 consults either or both of these lists prior to sending the
message to account
module 110 for signature. Recipients included in either list are stricken from
the message and,
27
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
if any valid recipients remain, the procedure continues normally. The user is
notified of any
recipients that were removed from his specified addressees.
The procedure described above involves a single recipient. When an outgoing
electronic mail message is addressed to multiple recipients it may be
processed in a different
manner.' In one embodiment of the invention, for example, multiple copies of
the outgoing
message are created, each one addressed to an individual recipient. Each
message is then
processed as described above.
In an alternative embodiment with multiple recipients, however, separate
copies of the
message are created only for recipients having an encryption key (e.g., a
public key of an
asymmetric key pair) stored on system 100. Thus, one copy of the signed
message is sent to all
recipients for whom no key is available. For each other recipient, a copy of
the signed message
is encrypted with the recipient's key before being transmitted.
Receiving a Communication for an Anonymous User
In addition to initiating transactions and communications, system 100 also
receives
messages and communications for anonymous users from third parties. In an
exemplary
embodiment of the invention, billing activity is directed to billing module
108, while validation
of messages sent by system 100 on behalf of anonymous users is performed by
account module
110. When, however, messages (e.g., electronic mail) or transaction details
are sent to a user,
they are received by an action module.
FIG. 5 depicts an illustrative method of receiving an electronic mail message
for a user
of system 100 from a third party. In the illustrated embodiment, users and
third parties need
not alter their methods of initiating, receiving and responding to electronic
mail messages. For
example, a third party responds to an electronic mail message from a user by
clicking on a
"respond" button or issuing a comparable command. Similarly, in composing or
addressing a
new mail message to an anonymous user, a third party need not alter his or her
normal
practices. The third party simply addresses the message to the appropriate
pseudonym (e.g.,
Anonymous 123 @Privada.Net).
In the illustrated embodiment, action module 114 is configured to receive
inbound
electronic mail. In an alternative embodiment, action module 112, which
handled outgoing
electronic mail messages, also receives incoming messages.
28
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
- With reference now to FIG. 5, state 500 is a start state. In state 502,
action module 114
receives an electronic mail message addressed to a pseudonym from a third
party.
Illustratively, action module 114 is coupled to the Internet or other wide-
area network via a
communication line.
S Action module 114 then queries account module 110, in state 504, to
determine
whether the indicated pseudonym corresponds to a valid account on system 100.
If not, action
module 114 is so informed and, in state 506, returns the message to the
sender. After state 506,
the process completes with end state 522.
In a present embodiment of the invention, if an account exists for the
addressed
pseudonym but is currently considered "invalid," the message is accepted and
stored but will
not be retrievable by the associated user until her account status is changed
to "valid."
Alternatively, the message is simply rejected if the addressed account is
"invalid."
After determining that system 100 maintains an account for the addressee in
state 504,
in state 508 it is determined whether the user accepts messages from the
originating third party.
In the presently described embodiment, a list is maintained (illustratively on
account module
110) of third parties from whom a user does not wish to receive messages. If
the originating
third party is included in this list, the message is returned to the sender in
state 506, possibly
with a message indicating that the user does not exist or does not wish to
receive messages
from the sender. In alternative embodiments of the invention, multiple lists
of unwanted
message senders are maintained, such as one for each user or some combination
of global or
semi-global lists along with individual lists.
Although states 504 and 508 are depicted separately in the illustrated
embodiment, in
one embodiment of the invention account module 110 examines the validity of
the user's
account in conjunction with determining whether the user accepts messages from
the third
party.
In state 510 it is determined whether monitor mode is active for the
addressee. In one
embodiment of the invention, this determination is made concurrently with
either of both of
states 504 and 508. For example, in response to the query in state 502,
account module 110
returns a message indicating that the addressee account is valid but
monitored.
If the addressee's account is not being monitored, the process continues at
state 514. If,
however, the account is being monitored, the process continues in state 512.
In state 512, a
copy of the message is made (e.g., by action module 114) and encrypted with a
public key of
29
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
the monitoring entity. As described above, when monitor mode is activated for
an account, in
one embodiment of the invention a pair of asymmetric keys (e.g., one public,
one private) is
generated (illustratively by account module 110). The private key is provided
to the entity
authorized to monitor the subject account, and the public key is used to
encrypt
communications and transaction details as they are processed by coordination
module 106.
When receiving an electronic mail message, however, in the presently
illustrated embodiment
of the invention action module 114 (e.g., rather than coordination module 106)
applies the
entity's public key to encrypt the message copy.
In state 514 action module 114 encrypts the received message with PuKl (from
Certl).
Next, in state 516 action module 114 stores the message in a file having a
file name unique
from all other stored messages (illustratively, the file name includes a time
stamp). All
messages received by action module 114 for users of system 100 are, in one
embodiment,
stored in a common area. This practice helps prevents anyone who may gain
access to this
pool of messages from determining which, or how many, messages are received
for a particular
anonymous user.
The unique file name corresponding to the message is forwarded in state 518 to
account
module 110. The file name is then stored in state 520 with some association to
the recipient's
pseudonym. In one embodiment of the invention an array, indexed by account
name, is
maintained. As messages are received for a particular pseudonym, the file
names of the
messages are stored in the array. In an alternative embodiment of the
invention, the file names
are stored in a location other than account module 114 (e.g., coordination
module 106). The
process ends with end state 522
FIG. 6 depicts an illustrative procedure in which a user retrieves her
electronic
messages from system 100. State 600 is a start state. In state 602, the user
logs into system
100 and establishes a user session. One method of establishing a user session
is discussed
above with reference to FIGs. 3A-3B. Then, in state 604, client 102 forwards a
bundle to
coordination module 106 having a TTC indicating that the user wishes to
receive her electronic
mail.
In state 606, a transaction handler passes the request (e.g., a package
containing the
user's pseudonym) to account module 114, which responds by sending a Iist of
stored messages
to client 102. In the presently illustrated embodiment of the invention, a
short description (e.g.,
subject line, originator) of each message is saved on account module 114 with
the unique file
CA 02335968 2000-12-22
WO 00/01108 PCT/US99/13908
names. Thus, account module sends some information concerning each mail
message to client
102. In an alternative embodiment, account module 110 and action module 114
work in
tandem to provide short descriptions to client 102. Illustratively, in this
alternative
embodiment action module 114 generates the identifying information in response
to a request
from account module 110.
In state 608, the user selects one or more messages to download. In state 610,
client
102 sends a request to account module 110 (via coordination module 106) for
some or all of
the messages stored for the user. Account module 110 then, in state 612,
retrieves the selected
messages from action module 114 and sends them to client 102.
Upon receipt, client 102 decrypts the messages in state 614 using PrKI . The
procedure
then ends in end state 616.
In the procedure described above, the incoming electronic mail message was
addressed
to only a single user or pseudonym. The procedure may be altered in the event
the message is
addressed to multiple users. For example, in one embodiment, a separate
message file is
created to store a copy of the message for each user listed as an addressee.
Each such file has a
unique name ar identifier, as in the procedure above. After the message is
copied and stored in
multiple files, the remainder of the message retrieval procedure is the same
as described above.
The foregoing descriptions of embodiments of the invention have been presented
for
purposes of illustration and description only. They are not intended to be
exhaustive or to limit
the invention to the forms disclosed. Accordingly, many modifications and
variations will be
apparent to practitioners skilled in the art.
In particular, two possible action modules have been described, for sending
and
receiving electronic mail, respectively. In alternative embodiments of the
invention, other
modules are provided. For example, an action module for outbound news is
within the scope
of the invention. An outbound news module illustratively receives a message
package from a
user at client 102 (through mask module 104 and coordination module 106). The
message is
passed to the account module where it is digitally signed (e.g., with the
user's PrK2) and
returned to the outbound news module. The outbound news module then posts the
signed
message to the newsgroup or other location specified by the user.
An action module in another embodiment of the invention serves as a web proxy.
A
web proxy module illustratively provides a user access to Internet web servers
(e.g., to view
31
CA 02335968 2000-12-22
WO 00/01108 PCT/US99113908
web pages). The web proxy module does not know the confidential or true
identities of the
user, or his IP address, but does know the user's pseudonym or account name.
In addition,
should a web server require validation of a pseudonym, the web proxy module
supplies the web
server with the user's Cert2, which can be validated by account module 110.
S In yet another embodiment of the invention, a commerce module is provided to
enable
anonymous electronic transactions through system 100. A commerce module
illustratively
learns the identity of the merchant that the user is dealing with, the prices)
of goods/services, a
description of what is being purchased or sold, etc. In a present embodiment,
the commerce
module retains only limited knowledge of the anonymous user (e.g., just the
user's pseudonym)
and uses billing module 108 to make payments to merchants. A unique
transaction identifier is
illustratively generated by the commerce module for use in tracking an order,
arranging
delivery of a purchase, or retrieving details of the transaction.
In view of these and other alternative embodiments of the invention, the scope
of the
present invention is intended to be limited only by the terms of the claims
below.
32
