CA 02328548 2000-12-15
Freedom 2.0 Mail System
1 I ntroduction
1.1 This Paper
The 2.0 release of Freedom, as it pertains to the mail system, implements a
completely
new design. It should not be thought of as an upgrade to the 1.0 Freedom mail
system,
but rather as a replacement of the previous design. This paper focuses on how
the
Freedom system handles email in all different cases, from both the server and
client end,
focusing more detail on the server-side aspects. From this point on, when we
use the
word "mail", we are actually referring to electronic mail, or "email". We do
not cover
security vulnerabilities extensively in this paper, and recommend the reader
searching for
such detailed coverage refer to Freedom 2.0 Security Issues and Analysis'. As
there is a
degree of overlap between various sections of this document, there is some
redundancy
in descriptions.
As of the 2.0 release of Freedom, there are two kinds of nym available:
standard nyms
and premium nyms. When a user purchases Freedom's "premium services", they
receive
an activation code that they exchange for tokens; these tokens are used to
create
premium nyms. Premium nyms have Freedom mail capabilities and full access to
the
Freedom Network for pseudonymous Internet privacy. Users who do not purchase
Freedom "premium services" receive standard nyms, which do not have Freedom
mail
capabilities. For the scope of this paper, we assume the user has premium
nyms.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
1.2 Assumptions
We assume you have already read and understood the Freedom 2.0 Architecture
document and understand terminology such as: nyms, public/private key pairs,
and
symmetric key pairs. We do not assume any knowledge of the Freedom 1.0
documents,
as the 2.0 release is a redesign of the Freedom System, as opposed to an
upgrade,
especially with respect to Mail handling. Readers who are familiar with the
Freedom 1.0
documents will better be able to appreciate the ways in which we have
redesigned the
mail system. Readers should be familiar with the basics of how POP mail works.
1.3 Freedom Mail Overview
As there were a number of usability, reliability, performance and security
problems with
the 1.0 system (the reply-block mail system), we have been designing a "next-
generation" mail system. While we have some preliminary candidate designs,
they will
take some time to explore, analyze, and implement. The 2.0 release of Freedom
comprises an implementation of a short-term fix: the POP mail system. The POP
mail
system primarily targets the usability and reliability aspects of the old mail
system, and
has the limited security objective of being no less secure, or at least of
similar security to
the old reply-block mail system.
To wit, Freedom users no longer need their own POP account in order to use
Freedom
mail. We provide a POP account for each nym, where mail is stored in encrypted
format
until the client retrieves it.
The objectives behind this POP mail system design were that it
~ should be easy to implement, so that we could roll it out within a short
timeframe.
should improve the usability experienced by customers
should be highly scalable, allowing us to support a growing customer base
~ should improve reliability of message delivery.
Pros
1. No reply-blocks
2. No activation tokens
3. Passive attacks seem to be harder
4. Mail retrieval hidden inside other freedom traffic
5. Lower bandwidth requirements
6. We have control over the operational reliability of the system
7. The system is conceptually simple and comprehensible
8. Should result in faster delivery
9. Should have greater operational reliability
10. Immediate availability of mail services after nym creation
11. Not vulnerable to legal attacks (i.e.: not subpoenable)
12. The user never get encrypted mail that they have to manually decrypt
13. The design is amenable to alternative user interfaces (web, access)
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
14. Mail is no longer stored in users' ISP accounts, removing the ISP as a
potential
attacker.
15. The design is amenable to quality of service payment options (e.g., user
can buy
more POP storage space for their nym)
16. We can leverage a great deal of existing, open, software to do most of the
work
Cons
1. Users must interact with the mail system separately for each nym in order
to avoid
giving Zero-Knowledge the power to correlate that their nyms may be owned by
the same
person.
2. Large infrastructure/storage requirements
3. ZKS could learn who sent a email to whom and when.
2 Glossary
This glossary explains the terms and how we will use them throughout the rest
of this
document. We will go into further detail on each of our own entities and
implementations
in section 4, Entities.
Nym As of the 2.0 release of Freedom, there are two kinds of nym available.
Users who install Freedom but do not purchase a serial number can
use the Freedom client and its standard features free of charge.
Standard features include several pseudonyms ("nyms") which do not
have Freedom mail capabilities, nor do they use the Freedom Network
for pseudonymous Internet communications. When a user purchases
Freedom "premium services", they are given a serial number which
they exchange for tokens, which in turn are used to create premium
nyms. Premium nyms have Freedom mail capabilities and full access
to the Freedom Network for pseudonymous Internet privacy.
For the purposes of this paper, we assume the user has premium
nyms, as any other scenario is pointless in the context of the Mail
system.
Cluster A cluster is a group of physical machines
which appears to a user to
be a single machine. Examples in the Freedom
Mail System are the
IMEP, and IMEPB.
MTA - Software which is responsible for the delivery
Mail of Internet mail from one
Transfer site to another. send mail, postfix, and
qmail are all MTAs. If one draws
Agent an analogy to letter and parcel delivery
in the "real world", an MTA is
equivalent to your favorite postal or courier
service; given a package,
they take the responsibility for routing
it from place to place such that
the the package eventually, you hope, reaches
its addressee.
MUA - Software which performs mail operations
Mail on behalf of the user. For
User Agentinstance: Microsoft Outlook, Netscape Messenger,
and Eudora are all
MUAs. If one draws an analogy to letter
and parcel delivery in the "real
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
world", an MUA is equivalent to a secretary or shipping clerk to which
you delegate the tasks of making sure that your package is addressed
properly and has the correct postage (i.e.: is well-formed Internet mail)
and who will walk down to the corner of the street to put your package
in the post box.
MAC - An authentication technique involving the use of a secret key to
Message generate a small fixed-size block of data that is appended to the
Authentication message. This is also known as a cryptographic checksum. This
Code technique assumes that two communicating parties, say A and B,
share a common secret key K. When A has a message to send to B, it
calculates the MAC as a function of the message and the key. The
message plus the MAC is transmitted to the recipient B. B performs
the same calculation on the received message, using the same secret
key, to generate a new MAC. The message is authentic if the newly
calculated MAC matches the received MACz.
The Mail System uses MACS in two different contexts. The Mail and
PKI Systems share a secret key. This shared secret is used by the PKI
system to generate an authentication certificate and a MAC key for
each nym. The Mail system used the shared secret to calculate a MAC
when attempting to validate an authentication certificate and to
reconstruct a nym's MAC key when forwarding Internet to nym mail.
Protocols
POP3 - A standard protocol used for the retrieval
Post of mail from a remote server.
Office When we say POP, we actually mean POP3,
which is version 3 of the
Protocol protocol. We have modified our POP server's
V3 authentication method
slightly, see section 4.4.3, POP server,
for more details.
SMTP - The standard protocol used for the delivery
of Internet mail. In its
Simple current deployment, the Freedom mail system
Mail speaks SMTP with the
Transfer Internet.
Protocol
ESMTP - An extension of the standard protocol used
for the delivery of Internet
Extended mail. In its current deployment, the Freedom
mail system uses a
Simple slightly modified ESMTP for authentication
Mail purposes.
Transfer
Protocol
QMQP - QMQP comes from Dan Bernstin's qmail package3.
Quick It is a wire protocol
Mail Queuingdesigned for rapid enqueueing of email
from multiple queue writers to
Protocol a shared message queue. Almost all Freedom
Mail System traffic
behind the firewall is in QMQP.
NFS - Network File System (NFS) is a file system
that will mount remote file
Network systems across homogenous and heterogeneous
File systems. NFS
System consists of a client and server system.
An NFS server can export local
directories for remote NFS clients to use.
It was originally developed
by Sun Microsystems Computer Corp. (SMCC)
and is now part of their
Open Network Computing (ONC) initiative.
All the Freedom Mail
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
System traffic behind the firewall that is not in QMQP is in NFS°.
NNTP - A standard protocol used to control how news messages are
Network News distributed, queried, retrieved, and posted. The Relay speaks
NNTP
Transfer when it sends news postings to News Servers.
Protocol
Servers
IMEP - These servers accept mail that originates
on the Internet at large and
Internet is destined for any given nym. IMEP servers
Mail implement the SMTP
Encryptionprotocol and are publicly accessible from
the Internet. IMEP servers
Proxy forward, using QMQP, all mail they receive
to a randomly selected
IMEPB (see below) for further processing.
These are stock mini-qmail
installations that access their QMQP servers
across a firewall.
IMEPB - These servers process and deliver Internet-to-nym
mail. IMEPB
Internet servers implement QMQP to accept and queue
Mail mail from any given
EncryptionIMEP. IMEPB servers are not accessible to
nyms or from the Internet;
Proxy only the IMEP servers can connect to the
IMEPB servers, and only for
Backend the purposes of enqueuing mail for delivery
via QMQP. These are
stock qmail installations with our scripts
put in to handle various paths.
They are completely behind a firewall and
accessible only from the
IMEP.
NMTA - These servers accept mail that originates
Nym from a nym and is destined
Mail Transferfor a nym, for a newsgroup or for an Internet
user. NMTA servers
Agent implement the ESMTP protocol and are accessible
to nyms via
anonymous routes whose exit node is a Core-AIP.
NMTA servers
authenticate the connecting nym and forward,
using QMQP, all mail
they receive to a randomly selected NMTAB
(see below) for further
processing. These are stock mini-qmail installations
with an ESMTP
patch and a custom password checking utility.
They are completely
behind a firewall and accessible only through
Core AIPS on the
Freedom Cloud.
NMTAB - These servers process and deliver nym-to-nym
Nym and nym-to-Internet
Mail Transfermail. NMTAB servers implement QMQP to accept
and queue mail from
Agent any given NMTA. NMTAB servers are not accessible
to nyms or from
Backend the Internet; only the NMTA servers can
connect to the NMTAB
servers, and only for the purposes of enqueuing
mail for delivery via
QMQP. These are stock qmail installations
with our scripts put in to
handle various paths. They are completely
behind the firewall, and
accessible only from the NMTA.
POP ServerThese servers implement the POP3 protocol
and allow nyms to
retrieve their email. The POP servers are
accessible to nyms via
anonymous routes whose exit node is a Core-AIP.
POP servers
authenticate the connecting nym, and if
they do not already have an
existing mail account, will create one.
These are stock qmail-pop3d installations, with a custom password
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
checking utility. These servers are completely behind the firewall and
accessible only through Core AIPs on the Freedom Cloud.
POP store This file system holds the nyms' mail until they download it. It is
completely behind the firewall and accessible only through the IMEPB
and the NMTAB.
Relay These servers perform final delivery of Internet and Usenet bound
messages on behalf of nyms. It also delivers failure messages to
Internet users if a nym bound message cannot be delivered. Its
primary purpose is to ensure that the other mail system entities do not
have to open connections outside of the mail system. This is a stock
qmail installation with a special delivery rule for the News case. It
bridges the firewall and accepts connections from the IMEPB and
NMTAB.
3 Paths
Internet User ~_~~.u~ --~ t'tP~=s<tc~e in tr:~=. cl~aL
- hle:;~ac~~: i:~ Encr,:)>tc~d
~t.1~'r,
----~. v!1S1I'
___ , Pdk~S
News
a rve r ra~ave~
rnt<rnc~r. Freedom
tai..; ,;, CI s a r
IIII~ ___~,Y_~ ..
IIIII NMTA '~, ra~~~n Ct7R
_.t ~ AIP',
RBLAY tae s
F Y '.lfsCi ~:'1
Cioua
III Il) VIII VIII
IMEP IS NM'~A$ h
Store
Figure 1: A high-level overview of how the Freedom Mail System works.
Freedom~ 2.0 Mail System
0 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
Here we describe the different paths mail follows depending on its originator
and
recipient. Please see section 4.3, Freedom Cloud, for information on how each
of these
paths is encrypted.
3.1 Nym Creation
The Mail and PKI systems share a secret key. When the PKI system creates a nym
on
behalf of a client it uses the nym's mail information in to construct a
certificate for the
nym. The veracity of the certificate is established by including a MAC that is
calculated
using the shared secret. More details on this certificate may be found in
section 4.12,
Mail certificate. It also uses the shared secret in order to generate a MAC
key for the
nym. Because the mail system also knows the secret, it is also capable of
generating the
MAC key when needed. More details on this key may be found in section 4.11,
Shared
nym-mail system MAC key. Both the certificate and the MAC key are returned to
the
client along with all other nym information. The PKI system has no further
need for the
MAC key, so discards it.
Given the certificate for the newly created nym, the client then attempts to
authenticate
itself to a Freedom POP server. The POP server validates the certificate by
calculating its
MAC using the shared secret and comparing it to the MAC contained in the
certificate. If
the nym proves to be authentic, then the server validates the presence of the
nym's mail
directory. If no mail directory is present, one is created and a "Welcome to
Freedom Mail"
message is sent to the nym.
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
3.2 Nym to Internet
1.1e:~,.:cy= i r~ t ti-= r l c-ut
- t~ls:.>-:a:cle i:v; ec,ct.,~~,ted
StMTF'
QIMC) P
r.; F
E'~ >P
--i. NNTP
Internet User
Freedom
User
IS1C2Y-ilEt
NE~Lv
n
A
I t
Ftwcd~~lr
N ~~ I I
_ ~'l~aud
CORE
AI F'
RELA
hIMTAE
Figure 2: A high-level overview of the nym to Internet path.
To support the transmission of mail from nyms to the Internet (i.e.: non-
Freedom mail
addresses) the SMTP proxy component of the Freedom client software will accept
plaintext connections from the end-user's MUA. After properly formatting the
mail, the
Freedom Client passes the Mail on to the NMTA speaking SMTP over an
unauthenticated route through the Freedom Cloud. The NMTA authenticates the
nym and
passes the mail on to the NMTAB, speaking QMQP. The NMTAB performs checks to
ensure the message may be sent, and then passes it on to the Relay, speaking
QMQP,
from where it is sent off to the appropriate MTA, speaking SMTP.
A more detailed breakdown of the steps each entity performs may be found
within section
4, Entities.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
3.3 Nym to News
.-.~Ilessage in
tre clear
Ilessage is
encrS~pted
SI3TI'
-.'.(~LItaY
__ N F:;
F'U F'
I..~~,NLQ~TP
Freedom
User
i
I
~~~~I I
News f
Server
Freedoo~,
C~.~ud
CORE
AIP
RELAY
NMTAB
Figure 3: A high-level overview of the nym to news path.
To support the transmission of news postings from nyms to Usenet, the NNTP
proxy
component of the Freedom client software will accept plaintext connections
from the end-
user's MUA. After properly formatting the posting, the Freedom Client passes
it on to the
NMTA speaking SMTP over an unauthenticated route through the Freedom Cloud.
The
NMTA authenticates the nym and then passes the posting on to the NMTAB
speaking
QMQP. The NMTAB, after performing various checks to make sure the nym may send
the posting, passes it to the Relay, speaking QMQP, from where it is sent to
the Freedom
Network News Host speaking NNTP.
A more detailed breakdown of the steps each entity performs may be found
within section
4, Entities.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
3.4 Nym to Nym
..'. t~4es~age i.r ttl~ cleat
- M~asag~ is encrypCed
-.-. SMTP
--~. (old~>P
IQF
P(iP
.--~. NT~1TP
Freedom
User
___
NMTA ~'~ CtRE:
~,
AI P ;
L.-,
~'_rny.?c~plP
t. loin.-i
~~AE op
Store
Figure 4: A high-level overview of the nym to nym path.
To support the transmission of mail from nyms to the Internet (i.e.: non-
freedom email
addresses) the SMTP proxy component of the Freedom client software will accept
plaintext connections from the end-user's MUA. After properly formatting and
encrypting
the mail, the Freedom Client passes the mail on to the NMTA speaking SMTP over
an
unauthenticated route through the Freedom Cloud. The NMTA authenticates the
nym and
passes the mail on to the NMTAB, speaking QMQP. The NMTAB, after performing
various checks to ensure the nym may send the mail, writes it to the receiving
nym's
mailbox over NFS.
A more detailed breakdown of the steps each entity performs may be found
within section
4, Entities.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 10
CA 02328548 2000-12-15
3.5 Internet to Nym
r~=;;s;vge in thr.: clear
- 1>.~:~;~<~ge i:enrrYprec~
;~ hlT P
~ 4~;It~F~
-- Id F,'>
Internet User ~''Y
_.s.- .~,m.,
Figure 5: A high-level overview of the Internet to Nym path.
To support the transmission of mail from Internet (i.e.: non-Freedom) users to
nyms, the
IMEP accepts and understands SMTP transactions with the Internet at large. The
IMEP
is configured to act as the mail host for all freedom.net email addresses. The
IMEP
passes messages on to the IMEPB, speaking QMQP. The IMEPB, after performing
various checks to make sure the mail may be sent, writes it to the receiving
nym's
mailbox over NFS. In the case of bounces or special aliased addresses (e.g.:
postmaster@freedom.net might be aliased to postmaster@zeroknowledge.com), the
IMEPB passes the mail on to the Relay, speaking QMQP, from where it is sent
off to the
appropriate MTA, speaking SMTP.
A more detailed breakdown of the steps each entity performs may be found
within section
4, Entities.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
3.6 Mail Retrieval
Freedom
User
Freedom
Cloud
Figure 6: A high-level overview of the mail retrieval path.
Mail retrieval is initiated when the POP proxy component of the Freedom Client
software
intercepts the user's MUA attempting to connect to a POP server. The Freedom
Client
authenticates itself to the POP server, speaking POP over an unauthenticated
route
through the Freedom Cloud, and downloads a list of messages to present to the
MUA. It
also connects to the user's POP server at his ISP and echoes the MUA's
requests to
obtain a list of messages. The Freedom Client then merges these lists into a
virtual
mailbox that it presents to the user's MUA. It then redirects the MUA's
processing through
the appropriate path so it can obtain the mail messages it requests.
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 12
CA 02328548 2000-12-15
In effect, the Freedom Client can talk to both the Freedom POP Server and the
user's
ISP POP server, and acts as a go-between for these two POP Servers and the
user's
MUA.
A more detailed breakdown of the steps each entity performs may be found
within section
4, Entities.
3.7 News Reading
The Freedom Mail System does not provide a pseudonymous news reading service.
Instead, we recommend the user to read news through a web interface using an
authenticated route over the Freedom Cloud if they wish to preserve their
privacy while
using Usenet. Please refer to "Freedom 2.0 Security Issues and Analysis" for
more
information.
4 Entities
4.1 Nyms
Nyms all need to have valid mail accounts that can send and receive mail. An
"account"
comprises:
~ a nym record in the nym database of the PKI system
~ public encryption and signature keys in the key database of the PKI system
(by
implication, the nym must have the corresponding private keys)
~ disk space in the mail system in order to store mail they receive
~ the configuration options denoting the operating parameters of the services
to which
the nym is entitled
The mail system representation of an account consists of a directory holding
per-nym
configuration files as well as the nym's stored mail. Mail is stored using
Maildir format
mailboxes. Maildir is a standard directory format that supports multiple
simultaneous
delivery agents and is reliable over NFS.
The location of the account directory is calculated as:
h =
32
bit
hash(
nym_name
)
i = h[23..20] )
hex(
j = h[19..16] )
hex(
k = h[15..12] )
hex(
1 = h[11..8] )
hex(
m = h[7..4] )
hex(
hex is the hexadecimal representation using lowercase letters.
mail dir = ${ACCOUNT ROOT}/i/j/k/1/m/nym name
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 13
CA 02328548 2000-12-15
This nym to directory mapping scheme is employed for the following reasons:
It provides a manageable level of fanout at each level such that the physical
distribution of the mail system storage can be spread across multiple file
servers
using different NFS mount points.
The hash distributes nym account (and hence nym storage) across the account
space. This helps to balance the load on the file servers.
And, the hash distribution serves to generally reduce the number of nym
accounts at
each leaf of the directory tree. The search performance of many file systems
degrades as the number of entries in the directory being searched gets larger.
The per-nym config files we store are:
.type The numeric identifier for the nym type
.quota The storage quota for the nym
.cross-post-limitMaximum simultaneous newsgroups in a
post
.tagline Indicates whether or not the Freedom
Mail System should append
tagline for nym to Internet traffic.
.send-limitmax recipients per 24 hours
.volume-limitmax bytes sent per 24 hours (not enforced)
blocklist.cdbhash of addresses blocked for delivery
Statl' counter for enforcing send-limit
Since it is impractical for each nym to have its own user id, we are utilizing
Paul Gregg's
method of hosting an arbitrary number of mail accounts from a single mail
system user
ids. All deliveries to nym accounts are performed under a single user id which
has
read/write access to the mail store. The entities utilizing this user id are
the NMTAB,
IMEPB, and the Freedom POP Server.
Since qmail-local receives knowledge of user directories by delegating to our
replacement version of qmail-getpw, frname2account, our password file does not
map
these directories or tell the POP server what the password should be. More
information
on user authentication can be found in section 4.13, Mail Certificate
Authentication
Protocol.
4.2 Freedom Client
This section describes how the Freedom Client distributed by Zero-Knowledge
handles
mail. Be aware, however, that since the Linux Client has been open-sourced,
there is a
chance that a Freedom Client provided by somebody other than Zero-Knowledge
may
not work entirely in this manner.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 14
CA 02328548 2000-12-15
4.2.1 Outgoing Mail
These are the common steps performed by the Freedom Client on all outbound
mail
regardless of whether the recipient is a nym, a non-Freedom Internet user, or
a
newsgroup. Upon receipt of an outgoing message, the Freedom Client's SMTP
proxy:
1. Sanitizes the message, ensuring that it does not contain compromising
information.
2. Modifies the message headers such that the sender is the currently selected
nym.
Internet Recipient
Assuming the previous common steps have been successfully completed, for
Internet
recipients, the Freedom Client's SMTP proxy:
1. Constructs an authentication signature header for each Internet recipient.
These can
be later used by the recipient to validate that the sending nym really did
send them the
message. (Section 4.14, Mail Message Format.)
2. Constructs a private route through the Freedom cloud to an NMTA.
3. Authenticates the nym to the NMTA using the nym's authentication
certificate. (Section
4.13, Mail certificate authentication protocol.)
4. Transmits the recipient list and the message.
5. Waits for notification from the NMTA that the message has been accepted for
delivery
before informing the user's MUA that the message has been accepted for
delivery.
News Recipient
Assuming the previous common steps have been successfully completed, for News
postings, the
Freedom Client's NNTP proxy:
1. Constructs a private route through the Freedom cloud to an NMTA.
2. Authenticates the nym to the NMTA using the nym's authentication
certificate. (Section
4.12, Mail certificate authentication protocol.)
3. Transmits the message using mail2news@freedom.net as the recipient.
4. Waits for notification from the NMTA that the message has been accepted for
delivery
before informing the user's MUA that the message has been accepted for
delivery.
Nym Recipient
Assuming the previous common steps have been succ3essfully completed, for
Internet
Recipients, the
Freedom Client's SMTP proxy:
1. Encrypts the message with the public encryption key of the recipient nym.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 15
CA 02328548 2000-12-15
2. Constructs a message authentication header for the encrypted message; this
header is
signed with the sending nym's private signature key and encrypted with the
recipient
nym's public encryption key. (Section 4.14, Mail message format.)
3. Composes a failure notification message to be delivered to the sending nym
if the mail
system is unable to deliver the message to the intended recipient. This
message is
encrypted using the sender's public-key (i.e.: the sender creates their own
failure
notification). (Section 4.6, Bounce handler.)
4. Appends the failure notification to the real message.
5. Constructs a private route through the Freedom cloud to an NMTA.
6. Authenticates the nym to the NMTA using the nym's authentication
certificate. (Section
4.13, Mail certificate authentication protocol.)
7. Transmits the message and the recipient.
8. Waits for notification from the NMTA that the message has been accepted for
delivery
before informing the user's MUA that the message has been accepted for
delivery.
4.2.2 Incoming Mail
To retrieve mail, for a given nym, the POP proxy component of the Freedom
Client
software:
1. Connects to a mail system POP server over an unauthenticated route through
the
Freedom Cloud.
2. Authenticates the nym to the POP server using the nym's authentication
certificate.
3. Downloads a list of the messages in the POP box.
4. Connects to the user's POP server at the user's ISP.
5. Echoes the POP authentication commands issued by the user's MUA to the POP
server at the user's ISP.
6. Presents the user's MUA with a consolidated list of the messages contained
in the user
and nym mailboxes.
7. Redirects each retrieval command issued by the user's MUA to the
appropriate POP
server for message download.
8. If the retrieval command refers to a message which resides on the user's
POP server
at their ISP then the message is forwarded through the proxy to the user's MUA
with no
other processing.
9. If the retrieval command refers to a message which resides on the POP
server in the
Freedom mail system then the message is first decrypted and verified by the
proxy
before being forwarded to the user's MUA.
10. Messages are deleted from the Freedom POP servers at the request of the
Freedom
Client POP proxy.
4.3 Freedom Cloud
All interactions with Core Freedom servers (PKI, KQS, and Mail) must occur
through a
Core AIP, which can only be accessed through either an authenticated or an
unauthenticated route through the Freedom Cloud. Sending and retrieving mail
involves
Mail System interactions over unauthenticated routes through the Freedom
Cloud. Public
key lookups for nym to nym mail involve interactions with the KQS over
unauthenticated
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
routes through the Freedom Cloud. Nym creation involves Nym Server
interactions over
authenticated routes through the Freedom Cloud.
4.4 Freedom Mail Servers
Internet User ~ ~~ --~' I''i~~~~=~s~~ in r.t;~- cl~~r
___ ne:~se~gN is encrypted
-.-~ SI~ITP
VIII -'-1 c>Yi~~F
_.~ fdF__.
News P~>P
Server ----~ r~:o~_os
f
~nr er n~~r Freedom
User
i ;.~,<,..; .;
I t~yt~~ I
(IIII Nh~TA '~, ta~y~tn COR
AI P
RELAY t~r.=' s
Freeczom
c o~.»3
III Ill VIII IIIII
IMEP = ~E NM'~'AB o)''
Store
Figure 7: The high-level overview revisited.
4.4.1 IMEP
The IMEP, upon the opening of a new ESMTP connection from an MTA
1. Validates that the recipient address is from the list of Internet domains
that the mail
system represents (i.e.: freedom.net).
2. Randomly selects an IMEPB.
3. Forwards the message to the IMEPB for further processing and delivery.
4. Waits for notification from the IMEPB that the message has been accepted
for delivery
before informing the MTA that the message has been accepted for delivery.
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
5. If it cannot contact the selected IMEPB, the IMEP selects another and
retries, until it
exhausts the set of IMEPB servers.
4.4.2 IMEPB
The IMEPB handles all the administrative and cryptographic manipulations
needed for
Internet to Nym mail. For the purposes of this section, the Internet sender is
referred to
as the sender, the recipient nym is referred to as the recipient, and a
specific mail
message is referred to as the message.
The IMEPB is a stock qmail installation with two sets of delivery rules:
.qmail-default
handles all nym deliveries using the following rules, and .qmail-remote with a
wrapper
script for handling bounce messages which may occur within the IMEPB. The
IMEPB is
completely behind the firewall, and sends its bounce messages to the Relay.
Upon receipt of mail destined for a nym, the IMEPB:
1. Checks to see if the nym is aliased to an Internet address; if so, the mail
is redirected
to that address (e.g.: postmaster@freedom.net might be aliased to
postmaster@zeroknowledge.com).
2. Validates that the recipient nym exists; if not, the message is bounced to
the sender
via the Relay.
3. If the recipient has enabled spam blocking, the message is examined to see
if it came
from a known spammer (as defined by the sending MTA being found in one or more
of
the known spammer lists consulted by the mail system). If the message is
determined to
be spam, it is discarded. (Section 4.7, Spam control program.)
4. Validates that the recipient nym has not blocked the sender; if so, the
message is
discarded. (Section 4.8, Blocklist.)
5. Verifies that the recipient nym has enough space in their mailbox to accept
the mail.
(Section 4.5, Mail store quota enforcer.)
6. Derives the nym MAC key from the Mail/PKI shared secret.
7. Constructs a message authentication header using the nym MAC key.
8. Encrypts the message authentication header using the public encryption key
of the
nym recipient.
9. Encrypts the message body using the public encryption key of the nym
recipient.
10. Adds the encrypted header and body to the recipient nym's mail box.
4.4.3 NMTA
The NMTA, upon the opening of a new ESMTP connection from a nym:
1. Authenticates the nym's authentication certificate by validating its MAC
using the
MaiIIPKI shared secret.
2. Validates that the sender address on the message envelope is the same nym
name as
that contained in the authentication certificate.
3. Validates that the sender address is from the list of Internet domains
which the mail
system represents (i.e.: freedom.net).
4. Randomly selects an NMTAB.
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 18
CA 02328548 2000-12-15
5. Forwards the message to the NMTAB for further processing and delivery.
6. Waits for notification from the NMTAB that the message has been accepted
for
delivery before informing the client SMTP proxy that the message has been
accepted for
delivery.
7. If it cannot contact the selected NMTAB, the NMTA selects another and
retries, until it
exhausts the set of NMTAB servers.
4.4.4 NMTAB
The NMTAB handles all the administrative and cryptographic manipulations
needed for
Nym to Nym and Nym to Internet mail. These two paths are handled separately
(though
they do perform some of the same functions). The NMTAB determines which path
to
follow by examining the To: field.
Basically, the NMTAB is a stock qmail installation with the following delivery
rules: .qmail-
default handles all nym-to-nym deliveries; .qmail-config-* handles special
configuration
deliveries, such as abuse@freedom.net; .qmail-mail2news handles news posting;
and a
replacement wrapper script for qmail-remote that implements our nym to
Internet deliver
rules.
The NMTAB, upon receipt of a new QMQP connection from an NMTA:
1. Writes the message to the queue.
2. Notifies the NMTA that the message has been accepted for delivery.
3. Validates that the nym has not exceeded their daily limit of outgoing mail.
4. Validates that the nym has not been blocked from sending mail to the given
recipients) (section 4.8, Blocklist), or in the case of a News posting,
validates that the
nym has not exceeded their cross-post limit.
Subsequently, in the case of Nym to Internet mail, the NMTAB queue handler
processes
the message by:
1. Validating that the mail contains one authentication signature header for
each recipient
(each recipient only receives their particular authentication signature
header, see section
4.14, Mail message format for further details).
2. Reforming each message in MIME format on a per recipient basis, stripping
signatures
for all other recipients. Please see section 4.9, Exploder, for more
information.
3. Submitting the message to the Relay, via QMQP, for final delivery.
4. Upon notification that the Relay has accepted the message for delivery,
removing the
message from the queue.
Subsequently, in the case of nym to news posting, the NMTAB queue handler
processes
the message by:
1. Checking if the user allows taglines. If so, attach tagline to message.
Please see
section 4.10, Tagline inserter, for more information.
2. Submitting the message to the Relay, via QMQP, for final delivery to
mail2news@news.freedom.net.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 19
CA 02328548 2000-12-15
3. Upon notification that the Relay has accepted the message for delivery,
removing the
message from the queue.
Subsequently, in the case of nym to nym mail, the NMTAB queue handler
processes the
message by:
1. Validating that storing the message in the recipient nym's mailbox would
not cause the
nym to exceed their storage quota.
2. If the message exceeds the recipient's quota, the pre-constructed failure
notification is
added to the sending nym's mailbox; otherwise, the main message is added to
the
recipient nym's mailbox. (Section 4.5, Mail store quota enforcer.)
3. The message is removed from the queue.
qmail-esmtpd We have extended some existing patches to qmail-smtpd which
enable
esmtp AUTH LOGIN style authentication checking, which it delegates to the
authentication system's checkpasswd (see section 4.13, Mail certificate
authentication
protocol, for more information). In addition, the esmtp patches compare the
authenticated
nym name to the envelope sender of each message, and reject non-matches. Also,
mixed message types (nym and Internet, or multiple nyms) are rejected as they
should
have been separated by the client.
4.4.3 POP Server
Our POP server is a stock qmail-pop3d installation with a replacement function
for
authentication. For more information on this process, please see section 4.12,
Mail
certificate authentication protocol.
4.4.4 Relay
The Relay is a stock qmail installation which negotiates with Mail Delivery
Hosts across
the Internet to deliver mail in its queue. In the special case of news, which
contain
domains of the form @news.freedom.net, it reforms the messages into one
compatible
with News servers, reforming the destinations to the actual newsgroups, and
then passes
them to Freedom Network News Server.
The Relay, upon receipt of a new QMQP connection from an NMTAB:
1. Writes the message to the queue.
2. Notifies the NMTAB that the message has been accepted for delivery.
Subsequently, for normal mail, the Relay queue handler processes the message
by
performing an SMTP delivery to the appropriate MTA. The Relay queue handler
processes message sent to mail2news@news.freedom.net by performing an NNTP
posting to the freedom network news host.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 20
CA 02328548 2000-12-15
4.5 Mail Store Quota Enforcer
The Mail Store Quota Enforcer ensures that each nym's mailbox doesn't exceed
the
amount of disk space that has been allocated to the nym.
Since all investigated out-of-the-box solutions for quotas have presented
incompatibilities
with our mail system design, the mail quota enforcer was implemented from
scratch. In its
current incarnation the quota enforcer is a C program that implements a simple
and
inefficient quota checking scheme.
4.6 Bounce Handler
In the case that mail cannot be delivered and the sender should be notified,
we have to
manipulate the message to deliver a properly pseudonymized and confidential
bounce
notice.
To facilitate this, the client constructs the proper bounce notification which
can be
extracted from the message by the mail system. With a MIME based message
format we
can use the reformime utility to extract the parts we want to store/bounce
when delivering
messages.
In this manner, we are able to ensure that the following goals are met
1. Mail is never dropped. Blocked mail is covered in section 4.8 and is
considered a
"successful delivery".
2. Nyms never receive any cleartext in their inbox, aside from the minimal
fields the pop3
daemon needs to see; (such as To : , From : , and s i ze).
3. Internet users find out when mail to a nym failed, receiving a message that
actually
makes some sense.
4. Nyms find out when their mail failed, and likewise receive a sensible, non-
alarming
message.
5. The postmaster finds out some lesser amount of information when a bounce-
loop
occurs; only enough information to diagnose the problem, not any cleartext
which could
be a privacy leak.
The bounce handler must be examined in each of the different contexts in which
it may
be invoked.
1. Internet to nym: a bounce is generated using the standard qmail bounce
mechanism if
any of the quota checks fail or if the nym does not exist. The cleartext
message is
returned.
2. Nym to Internet: the bounce message enters the mail system via the IMEP and
is
handled as a normal Internet to nym message, and is called only if the mail
had reached
the Relay before bouncing.
3. Nym to nym: the sender sends a 2-part MIME message (as formatted by the
client),
whose second part is a short, explicit bounce message pre-encrypted for
themselves. If a
bounce occurs, the second part of the MIME message is extracted, formed into
its own
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 21
CA 02328548 2000-12-15
MIME message, and sent back to the sender. Otherwise, the non-bounce portion
is
extracted and reformed into just the message and sent on to the recipient.
4. Internet to Internet: our mail system does not relay for any non-nyms,
rendering this
bounce functionality moot.
4.7 Spam Control Program
The spam control program is optionally called in the Internet to Nym case to
block known
spammers, using Realtime Blackhole List (RBL) style authentication.
A modified version of rblcheckfi (changes fed back upstream) is configured as
a qmail-
command' delivery target. Mail is sent to it on stdin, it parses the qmail
Received: line
and looks the connecting IP up in a variety of anti-spam DNS servers. If any
of the tests
succeed (the mail is from a spam source) the program exits 99, aborting
further delivery
attempts. If all tests fail, the program exits 0, and qmail-locale will carry
on delivering to
the user's Maildir.
4.8 Blocklist
The message blocking functionality searches a list of items to see if a given
sender or
recipient has revoked, or had revoked, their permission to perform a given
operation. This
is used for:
~ Revoking nym access to the mail system
~ A nym wishing to block delivery from unwanted senders
~ An Internet address wishing to block delivery from unwanted nyms
This allows us to, on behalf of both Freedom and non-Freedom users, make sure
that an
email recipient can request (and have enforced) their desire not to receive
unwanted mail
from a particular sender or domain delivered via the Freedom mail system. We
want to
silently drop messages through conversations that have been expressly blocked.
There are four situations where we would want to "block" a user or combination
of users:
1. Block on Log-In to POP server
If we wish to be able to revoke the mail system usage privileges of a nym the
authentication system checks whether or not the nym attempting to authenticate
itself is
located in a blocklist.
2. Block on Log-In to NMTA
If we wish to be able to revoke the mail system usage privileges of a nym the
authentication system checks whether or not the nym attempting to authenticate
itself is
located in a blocklist.
3. Block on Internet Delivery
When attempting to deliver a message from a nym to an Internet address, we
validate the
following conditions:
~ the sender is allowed to have mail delivered on their behalf;
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 22
CA 02328548 2000-12-15
~ the recipient has not requested that all mail from the Freedom network to
their
address not be delivered;
~ the recipient domain has not requested that all mail from the Freedom
network to
their address not be delivered;
~ the recipient has not requested that all mail from the sending nym to their
address not
be delivered;
~ and the recipient domain has not requested that all mail from the sending
nym to their
address not be delivered.
4. Block on Nym Delivery
When attempting to deliver a message to a nym, from either an Internet address
or
another nym, we validate the following conditions:
~ the sender is allowed to have mail delivered on their behalf;
the recipient has not requested that all mail from the sender not be
delivered;
~ and the recipient has not requested that all mail from the sender's domain
not be
delivered.
The blocklist functionality is implemented by storing the block list within
the mail system.
This is combined with a filter rule to the delivery mechanism which checks
that the sender
isn't in that list. To update the block list, a nym sends a new list to the
reserved nym
blocklist@freedom.net (all done by the client) that validates that the sender
is legitimate,
runs the plaintext link through the hashing function, and replaces the block
list stored for
the sender with the one contained in the message. The list of blocked senders
contains a
hash of the names rather than the actual sender names (for privacy purposes).
Blocklists
are accessible to the mail system, but are not a matter of public record.
We implemented this functionality by maintaining a database of revoked target
recipient
pairs. This is a database of keys without corresponding values. The presence
of a key in
the database indicates that the sender-recipient pair it represents is a
disallowed delivery
path. Thus, a blocklist is a database of keys having the general form:
hash([sender][->recipient])
where sender is the email address or domain of the sending party and recipient
is the
email address or domain of the receiving party. Both sender and recipient are
optional.
When the system wants to validate that a particular operation is allowed to
take place, it
searches for the appropriate key in the database. For instance, if the mail
system want to
validate that it is allowed to deliver mail to an Internet recipient on behalf
of a particular
nym, it performs the following steps:
1. normalizes the sender;
2. normalizes the sender's domain;
3. normalizes the recipient's domain;
4. normalizes the recipient;
5. checks if "hash ( sender) " is in the database;
6. checks if "hash ( sender domain) " is in the database;
7. checks if "hash ( - >recipient ) " is in the database;
8. checks if "hash (->recipient domain) " is in the database;
9. checks if "hash (sender->recipient domain) " is in the database;
10. and Checks if "hash (sender->recipient) " is in the database.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 23
CA 02328548 2000-12-15
If any key is found in the database then the mail is discarded by the mail
system.
The following sample global blocklist is implemented in the following manner.
Here is the
plaintext blocklist:
alice@freedom.net,bobQhotmail.com
aol.com
,foo@bar.net
The mail system will convert it into a CDB archive. The example blocklist
prohibits
1. aliceCafreedom.net from sending to bob@hotmail.com
2. anyone from aol.com from having their mail delivered to the recipient
3. anyone from sending mail to foo@bar.net
Typically the nym->Internet blocklist will contain the first type of entry
(i.e.: blocking
specific conversations) where the sender is a particular nym and the recipient
is either an
email address of a domain.
Typically a nym blocklist will contain the second type of entry (i.e.:
blocking specific
senders) because the recipient is denoted by the owner of the list, and is
therefore
redundant. The sender may be either a specific email address or a domain.
4.9 Exploder
When a nym sends to the Internet, we cannot know which envelope recipients are
Bccs
and which are supposed to know about each other. As a result, we must generate
separate authentication headers for each possible recipient and separate them
out during
remote delivery. This process was initially called "exploding" the mail,
before we learned
that qmail's remote delivery policy is to always deliver each recipient
separately along its
own connection. Our task is made simpler: we simply strip out, in each
delivery, the
authentication headers which do not correspond to the current envelope
recipient; ensure
the From field matches the sending nym. The x-Freedom-Envelope-sig header can
only be used to verify that the sender did or did not originate a message to
the recipient.
It cannot guarantee the other To or cc fields are accurate, nor can it
guarantee the
message hasn't been tampered with.
To facilitate this task, we have designed the net2nym authentication header to
be easy to
grep for. It takes the following form:
X-Freedom-Envelope-Sig: recipientQisp.net
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 24
CA 02328548 2000-12-15
Thus, an email message being sent to bob, alice and Fred might appear
something like
this:
X-Freedom-Envelope-Sig: bobosecret.gov
oi3hj4bOb0ihjbrojkgfbOgdhbv97863764ghjbg0
X-Freedom-Envelope-Sig: aliceQevil.com
03iub0ufb08734bo3hb09u3bvr9ubfi0u3brOfb03
X-Freedom-Envelope-Sig: fredC~naive.org
3rfg9u43ygr934gf9ugr9uhfb394gf934ugf9uyfg
From: Joe the Mischevious <fredOtrouble.net>
To: Bob The Intrepid <bob~secret.gov>
Cc: Alice the Wealthy <alice0evil.com>
Subject: How evil can you get?
hey, I was wondering, have any of you been doing really bad stuff to Fred
recently?
-joe
which would subsequently be delivered as the 3 separate messages:
X-Freedom-Envelope-Sig: bobOSecret.gov
oi3hj4bOb0ihjbrojkgfbOgdhbv97863764ghjbg0
From: Joe the Mischevious <fredotrouble.net>
To: Bob The Intrepid <bob~secret.gov>
Cc: Alice the Wealthy <alice~evil.com>
Subject: How evil can you get?
hey, I was wondering, have any of you been doing really bad stuff to fred
recently?
-joe
X-Freedom-Envelope-Sig: alice@evil.com
03iub0ufb08734bo3hb09u3bvr9ubfi0u3brOfb03
From: Joe the Mischevious <fredc~trouble.net>
To: Bob The Intrepid <bobosecret.gov>
Cc: Alice the Wealthy <alicec~evil.com>
Subject: How evil can you get?
hey, I was wondering, have any of you been doing really bad stuff to fred
recently?
-joe
X-Freedom-Envelope-Sig: fredc~naive.org
3rfg9u43ygr934gf9ugr9uhfb394gf934ugf9uyfg
From: Joe the Mischevious <fred~trouble.net>
To: Bob The Intrepid <bobQsecret.gov>
Cc: Alice the Wealthy <alice~evil.com>
Subject: How evil can you get?
hey, I was wondering, have any of you been doing really bad stuff to fred
recently?
-joe
4.10 Tagline Inserter
For nym to Internet mail, if the sending nym has not turned off the tagline
option, this
function appends/inserts the Freedom tagline into the message.
Freedom~ 2.0 Maii System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 25
CA 02328548 2000-12-15
The basic approach is to send all outgoing mail thru a pipeline, which pipes
the message
to stdout if they have turned off this option, and otherwise pipes to a MIME
unpacker,
followed by a concatenation of the tagline and a MIME re-packer.
The tagline inserter first converts its input to a MIME multipart message (if
needed). It
then examines the MIME parts of the email and appends the supplied tagline to
the
appropriate places. If the MIME type of the message is multipart/alternative
then the
tagline is appended to the first plain text and the first HTML parts of the
message. If the
MIME type is single part text or HTML then the tagline is appended only to the
appropriate part.
If a text/plain or texdhtml is base64 encoded, that part is first decoded, the
tagline is
appended, and the part is re-encoded.
If no text/plain or text/html part is found in a multipart/mixed message, a
new text/plain
part containing only the tagline is added to the message.
4.11 Shared Nym-Mail System MAC Key
In order to save public key signature operations in the mail system, we have a
secret
shared between the mail system and each nym. This symmetric secret is
generated by
the nym server at nym creation time, and sent back with the mail system
authentication
certificate. The nym server erases its copy after transmission to the client.
Please see
section 4.12, Mail certificate, for more information on the Mail Certificate.
The client stores the shared secret with the same security as private keys,
the mail
system certificate, and so on. It never needs to transmit the shared secret;
it only uses it
to verify MACS on downloaded mail from the Internet.
The key is generated, by the nym server, like so:
key = SHA-1(secret ~~ entity)
where secret is the secret shared between the mail system and the nym system,
and
entity is the entity identifier of the newly created nym (i.e.: entity type
and name).
The mail system is able to generate this key on-the-fly, as it knows both the
secret and
the entity.
Should the secret change (e.g. after a detected compromise), the nym will no
longer be
able to authenticate itself to the mail system because its certificate is
invalid. It will
connect to the nym server to get a new certificate, and at the same time get a
new MAC
key. MAC verifications on existing mail will fail, but this is the proper
behavior, assuming
a compromise.
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 26
CA 02328548 2000-12-15
4.12 Mail Certificate
The certificate is generated by the Nym Server at nym creation time, and sent
to the user.
This certificate is used as a password in interactions with the NMTA and the
POP Server.
At the same time, the nym server also generates and sends the MAC key shared
by the
mail system and the nym. Please see section 4.11, Shared nym-mail system MAC
key,
for further information.
If the secret key shared between the Freedom Mail System and the Freedom Nym
Server
is compromised, the Freedom server operators will change it upon detection.
This will, of
course, invalidate all the certificates and shared Mail-Nym MAC keys. Upon the
Freedom
Client's next authentication attempt, the mail server check-password function
tells the
user that the user name and authentication failed. Then the nym re-
authenticates itself to
the nym server using its private signature key, and obtains a replacement
certificate
using the new secret key.
The certificate is only legible to the Nym Server and the Mail System, because
it is signed
by the MaiI/PKl shared secret. A certificate looks like this:
pkt-pkt- ent vers exp type mail vol size crossmac
verstype (2) (8) (1) (4) (4) (4) (4) (10)
(1) (1)
where the fields are:
pkt-vers A 1 byte value indicating the version of this packet format,
currently 1
pkt-vers A 1 byte value indicating the type of this packet, currently 1.
ent The name of the nym, preceded by a 1-byte type.
vers The version of the mail certificate.
exp The expiration date of the certificate (from a ZkClock object).
type The type of the account of the entity, (e.g.: premium).
mail The mail-limit (maximum number of mail a user can send).
vol The volume-limit (maximum number of bytes a user can send).
size The pop-quota (maximum size, in bytes, of the owner's mailbox).
cross The cross-post limit (maximum number of simultaneous newsgroup the user
can send).
mac The 10-byte mac over the preceding bytes.
All multi-byte data fields are considered to be in network byte order (big
endian).
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
4.13 Mail Certificate Authentication Protocol
In the POP mail system, we are building upon the existing authentication
mechanisms of
POP, and ESMTP. However, these mechanisms typically involve the user sending
his
username and password to the server, and the server having a database of user
names
and passwords, which case we want to avoid.
The following authentication protocol is designed to remove a database lookup,
and to
allow the user's password to securely pass attributes about the user. In
particular, we
want to avoid having to contact the nym server or key server in order to
authenticate the
user, as these transactions waste time and processing power, as well as
inhibit
scalability.
The secret key is shared by the mail system and the Nym Server. When the user
connects to the mail server using ESMTP or POP, he sends his nym name as the
USER
and the certificate as the PASS field. In the future, the mail system will
store the nym's
current certificate version in a file in its mail directory, enabling it to
cheaply verify the
certificate using the check-password function, which will just verify that the
MAC is valid,
and that the version numbers are correct.
The certificate may never be sent in the clear to the mail server, as someone
may snoop
on the connection and get it. The certificate authentication mechanism is
vulnerable to
replay if used directly so must always be used inside an encrypted tunnel,
which has
replay protection, or inside trusted networks. For this reason, it is only
used by the
Freedom Client in the context of unauthenticated routes through the Freedom
Cloud.
If the secret key shared between the Freedom Mail System and the Freedom Nym
Server
is compromised, the Freedom server operators will change it upon detection.
This will, of
course, invalidate all the certificates and shared Mail-Nym MAC keys. Upon the
Freedom
Client's next authentication attempt, the mail server check-password function
tells the
user that the user name and authentication failed. Then the nym re-
authenticates itself to
the nym server using its private signature key, and obtains a replacement
certificate
using the new secret key.
4.14 Mail Message Format
Following RFC 822, a mail header consists of two parts: the field-name, and
the field-
body. For example, in
From: bob@freedom.net
From is the field-name, and bobc~freedom. net is the field-body.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 28
CA 02328548 2000-12-15
We assume the user's mail user agent (MUA) produces a message like the
following:
From: Nsnd
To : N rcv, , I rcv,
cc: Nrcv~, Ircv
scc: Nrcvb, Ircvb
text
where N represents a nym, and I is a non-Freedom (Internet) user (there can be
more
than one recipient for each type). Therefore, Nrcv~ would be the nym recipient
from the
Cc header. Call this I~/~or;g, the original message, which includes both the
RFC 822
headers and the text.
4.14.1 Pre-Processing Stage
These are the steps performed by the Client and IMEPB for all mail they
handle. After
this stage has been completed, the next set of rules to follow depends on the
recipient
type.
Client-side operations
1. Sanitize the headers on the original message, removing anything that might
identify
the Freedom user (as opposed to the nym). Call the resulting sanitized message
Msan
2. Break up the recipients into the following classes:
~ each nym recipient, whether in a To, cc or scc header becomes the sole
member of
its own class
~ each non-nym recipient in a Bcc header becomes the sole member of its own
class
~ all non-nym recipients in To and cc headers become members of the same class
This classification is necessary because the format of the message differs
according to
whether the recipient is a nym or not (mail to nyms needs to be publicly
encrypted with
their key; mail to an Internet user doesn't), and because non-acc recipients
must not be
aware of scc recipients.
3. For each class of recipient make a copy of Msan, using the exploder
functionality.
(Section 3.9, Exploder.)
4. For each class of recipient generate a list of their names for the
recipients header of
the message envelope.
5. If the recipient is an Internet address, create an x-Freedom-Envelope-sig
header
containing a base-64 encoded signature over the field-bodies of the two
headers: From
and To. Add this header to Msan. This signature can only be used to verify
that the
sender did or did not originate a message to the recipient. It cannot
guarantee the other
To or cc fields are accurate, nor can it guarantee the message hasn't been
tampered
with. In the nym recipient case, the client verifies this signature. In the
Internet recipient
case, Zero-Knowledge's Abuse department will verify signatures on a case by
case basis.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 29
CA 02328548 2000-12-15
1MEPB-side operations:
1. Break up the recipients into the following classes:
~ each nym recipient, whether in a To, cc or scc header becomes the sole
member of
its own class
We don't need to worry about any of the other classifications we saw in the
Client-side
operations because the IMEP will not accept mail destined for non-Freedom
users.
2. For each class of recipient make a copy of the message and call it Msan,
using the
exploder functionality (section 4.9, Exploder).
3. For each class of recipient generate a list of their names for the
recipients header of
the message envelope. Since each nym is put in its own class, the To header of
these
message envelopes should each contain one and only one name.
4.14.2 Internet Recipient
If the Pre-processing stage has been followed by the client, the mail is now
ready for
delivery to the recipient and is passed off to the NMTA.
4.14.3 Nym Recipient (Including News)
This section describes the format of the message destined to a nym, either
from a non-
Freedom user (via the IMEP), or from another nym. It is assumed that the
previous steps
have been followed by the client or IMEPB, and that we now have a copy of Msan
1. Create a special binary header, Hmsg, containing the following fields
sender [ + Internet email address ]
recipient
hash(Msan)
flag
{SNsnd)(hash(sender, recipient, hash(Msan)))
In the Internet sender case, the sender field will be the NMTAB and there will
be an
Internet email address field based on the message envelope sender (which will
be used
for the blocking list). For the nym sender case, the client ensures that the
sender field is
the sending nym's name. Since the mail is destined to a nym, there can be only
one
recipient. The flag field indicates whether the message is authenticated with
a MAC
(value is 0) or a signature (value is 1). When a nym sends mail to another nym
it will use
a signature, signing with its private signing key, while the NMTAB will
generate a MAC
using the secret shared with the recipient nym. (Section 4.11, Shared nym-mail
system
MAC key.)
2. Encrypt Msan using the recipient nym's public encryption key.
3. For the nym sender case, the client generates a bounce message, Mbounce
that will be
delivered to the sender in case of an error. The bounce message has a header,
f"~bounce,
that is similar to Hms9, with the exception that the sender and recipient
fields are both the
sending nym's name. The bounce header and message are publicly encrypted with
the
Freedoms 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 30
CA 02328548 2000-12-15
sending nym's encryption key. More information on the bounce message may be
found in
section 4.6, Bounce handler.
4.Compose all these pieces into a MIME message
base64(Msan)
baSe64(Mbounce)
If the message cannot be delivered, it is reformed keeping just the bounce
section and
placed in the sending nym's mailbox, and the rest of the message is be thrown
away. If
the message can be delivered, it is reformed with the bounce section removed.
As far as the Client is concerned, newsgroups postings are like sending mail
to a nym
with the following exception: the message must contain one or more headers of
the form:
group-nameC~news.freedom.net
This functionality is implemented by having the qmail user news@freedom.net be
a
special alias which has its own public and private keys and delivery script.
When the
NMTAB receives mail destined for the news alias, it decrypts the message using
the
alias's private key, verifies the message's integrity, and then proceeds with
the tests
described in section 4.4,2, NMTAB.
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 31
CA 02328548 2000-12-15
Reference
Cameron Liard's notes on MTAs
http://starbase.neosoft.coml-claird/comp.mail.misc/MTA comparison.html
"Life with qmail". Dave Sill http://Web.InfoAve.Net/-dsill/lwq.html
http://stommel.tamu.edu/-baum/IinuxlLDP/HOWTO/mini/Mail2News-9.html
http://www.tibus.net/pgregg/projects/qmail/single-uid-howto.html
safecat, http://www.nb.net/-Ibudney/linux/software/safecat.html
maildrop, http://www.flounder.net/-mrsam/maildropl
ORBS, http://www.orbs.org
mail-abuse.net, http:/lwww.mail-abuse.net
Endnotes
' "Freedom 2.0 Security Issues and Analysis", Adam Back, Ian Goldberg, Adam
Shostack, Zero-Knowledge Systems, Inc.
2 The Networking Dog Glossary
http://www.networkingdog.net.au/Glossary/MessageAuthenticationCode.htm
qmail D. J. Bernstein http://www.qmail.org
"The PC-Mac TCP/IP & NFS faq" (comp.protocols.nfs)
http://www.rtd.com/pcnfsfaq/SecA.html
5 http:/Iwww.tibus.net/pgregg/projects/qmail/single-uid-howto.html
6 http://rblcheck.sourceforge.net/
' http://www.qmail.org/man/man8/qmail-command.html
a http://www.qmail.org/man/man8/qmail-local.html
Freedom~ 2.0 Mail System
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 32
CA 02328548 2000-12-15
Freedom System 2.0 Architecture
Abstract
This white paper, targeted at the technically savvy reader, offers a detailed
look
at the Freedom 2.0 System architecture. It is intended to give the reader a
good
understanding of the components that make up this system and the relationships
between them, as well as to encourage analysis of the system.
Introduction
The Freedom product line is designed to be the most integrated, strongest and
easiest-
to-use privacy system available. This white paper gives the technical reader a
good
understanding of each component and of the system as a whole.
This paper focuses on the Freedom 2.0 system architecture. It will first list
a set of key
features of the system, followed by an overview of the network and a
description of each
major software component. It replaces the architectural information presented
in the
"Freedom Network 1.0 Architecture" document'.
This paper concentrates on the Freedom System architecture as it exists at the
time of
publication. It does not discuss the future directions of the system
architecture nor does it
describe the protocols used by the system, These are discussed in the Freedom
2.0
System Protocolsz document.
Key New Features
A number of key new features have been implemented in the 2.0 version of
Freedom
which set it apart from the previous version. These are:
A Single Network
All Freedom operations are done on a single network. No separate software or
infrastructure is required to support different types of nyms and their
security levels.
There is a single nym namespace and a single domain name, freedom.net.
Kernel Space AIP
The AIP now operates inside the Linux kernel of a Freedom Server Node to route
encrypted traffic. This allows it to reduce operational overhead thus
providing much
Freedom r"~ System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
improved performance over the previous version of the Freedom AIP. This allows
us to
increase the overall amount of data that can be transported through the
Freedom System
and the speed at which this traffic can be processed.
Scalable Core Systems
The various servers that comprise the Freedom Core Systems have been made
scalable.
Multiple instances of each server type can now be run to support the needs of
a greater
number of Freedom clients.
A Clearly Defined Threat Model.
A cleaner threat model' for the Freedom System has been defined. This allows
the
Freedom System design to better focus against attacks and removes certain
constraints
that intertere with the Freedom System's network performance.
A New Mail System
The reply block mail system has been completely replaced by a POP box-based
mail
system hosted by Zero-Knowledge Systems, Inc. This dramatically increases the
performance of the system. It can support a large number of users and provides
them
with simpler, more secure, and faster mail services.
Freedom System Overview
The Freedom Network is an overlay network that runs on top of the Internet. It
uses
layers of encryption to allow a Freedom user to engage in a wide variety of
pseudonymous activities, hiding the user's real IP address, email address, and
other
identifying information from eavesdroppers and active attempts to violate the
user's
privacy.
Users are encouraged to create pseudonyms ("nyms") for each area of activity
in which
they want to preserve their privacy. The nyms that someone uses cannot be tied
together. Thus, it is not possible to say if superman@freedom.net and
clarkkent@freedom.net are the same or different people. Superman is happy with
this
situation because he doesn't want his supervillain enemies to know about his
life.
Similarly, when jobseeker@freedom.net browses a resume web site, his employer
cannot
see that Clark (''jobseeker") isn't happy with his job at the Daily Planet and
wants to work
elsewhere. Freedom protects Clark's privacy by proxying the various supported
protocols,
and sending those proxied packets through a private network before they are
deposited
on the Internet for normal service. That private network, as a system, is
operated by
Zero-Knowledge. Individual nodes in the network are operated by Zero-Knowledge
and
our partners, so that no single operator has comprehensive knowledge of what
data is
flowing through the network. Thus, the main components of the system are nyms
and
Freedom Servers. In the next section, we offer precise definitions of these
and other
entities.
Freedom T"' System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
Freedom Network Layout
The Freedom System consists of a set of Freedom Server Nodes that make up the
Freedom Network, and the Freedom Core Servers that provide basic services. The
network transports encrypted IP traffic from one node to the next. Nodes on
the Freedom
Network are called Anonymous Internet Proxies (AIPs). The number of nodes used
in a
route is chosen by the user by setting her security level in the Freedom
client. The server
nodes themselves are not linked by a fixed topology, instead, they can
communicate with
any other server node on the network, as requested by a client when creating a
route.
The Freedom client is given a network topology that identifies a set of
reliable links
between nodes in order to simplify route selection. This topology is defined
solely on the
basis of AIP-AIP performance characteristics.
Freedom
Client
Core Servers ~ Core AIPs
Fn.E.m
3erwr
N.G
FreeU.n.
N.x
PKI Server
Cluster
Fnead.m
Fml.m
sen.r
N~°° Freedom
Network
F,eeMn
S.rvv "
N~
Network Intormatfon F'°""'
Server Cluster .~ ~" Fs ~~
.. Nek
Fr.eem
Sera
Nole
Fre.lon
r
Mail System
Cluster
Zero Knowledge Systems
Faeaane.e",aearr"FK ~~~ ~ Internet
aeee~a~rearwrr .."..,.,............,.., Server
a«r u.w~iee rrrrK . ... .. . ...
Figure 1: Freedom Network Layout
Authenticated routes to an exit AIP are granted through route creation
requests signed by
a nym. Upon receipt of such a request, an AIP will retrieve the requesting
nym's public
signature key and verify the request. Only nyms that have full access to the
network can
create such a route. Authenticated routes allow access to any host on the
Internet.
Unauthenticated routes to a core AIP are granted to any Freedom client that
requests
one. These are limited in that only Freedom core servers can be accessed.
Freedom'"" System 2.0 Architecture S-
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
The core servers consist of PKI server clusters, reporting and network
information server
clusters, a token server, and the mail system. The core servers are accessed
by creating
completely anonymous routes that terminate at a core AIP. These are the only
AIPs on
the Freedom Network capable of accessing the core servers.
Freedom Network Server Nodes
A Freedom server node is a host running part of the Freedom Network. This node
can be
administered by Zero-Knowledge or by a third party server operator. A Freedom
server
node consists of an AI P, a local NIQS daemon client, some administration
utilities and a
set of key generation utilities.
The node's operator generates the signature and cryption keys and submits the
public
components to Zero-Knowledge Systems for distribution to the rest of the
network. Zero-
Knowledge Systems never sees the node's private keys, thus ensuring that only
that
node is capable of decrypting its layer from the traffic that goes through it.
The server node software needs to be able to communicate with the key query
servers,
NIQS, NISS, and other AIPs on the Freedom Network. It accepts connections from
Freedom clients wanting to transport encrypted IP traffic on the Freedom
Network.
A Freedom server node also runs a DNS server which is used to respond to DNS
queries
generated by a Freedom client. This is done through the same authenticated
route as the
client that issued the query, thus ensuring that any hostname lookup done by a
Freedom
user is completely anonymous and private.
Freedom Core Systems
The Freedom Core Systems provide the base services which keep the Freedom
Network
running. This includes providing public keys, nym creation and update, network
information and reporting, token creation, and the mail system. All of these
services are
currently provided by Zero-Knowledge and are located within our machine room.
This
new architecture introduces the concept of a core AIP that allows
unauthenticated
connections to any of the core servers in the network. The servers are no
longer
constrained by performance limitations or affected by the AIP running on the
same host,
as they were in the previous version of the system. Multiple instances of each
core server
type are also now supported. This allows the Freedom System core to load
balance
incoming requests across several machines as required.
Software Components
This section describes the Freedom System components that make up the
architecture
design, including the Freedom client, AIP, network information and reporting
system, PKI
servers, and the mail system.
Freedom'"" System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. .3 ~O
CA 02328548 2000-12-15
Freedom Client
The Freedom client allows networking applications running on a computer to
access the
Internet through the Freedom System. It is designed to work seamlessly with
these
applications by trapping and redirecting the data streams that they generate.
What
follows is a simplified description of the client that applies to both the
Windows and Linux
versions. A more thorough description is beyond the needs and scope of this
document.
The Freedom client consists of several components: a graphical user interface,
a network
access layer, a traffic filter, application filters, and a set of libraries
which implement the
functionality required for encryption, routing, nym management, route
creation, etc.
Network Application ~ - Freedom Client
Netscaae.0utlook...) Graphicallnterface
Networkin calls
(connectp, send~op...)
Network API
Winsock 2 sockets
working calls
'~ ~~ _ A lication
Network Access ~ - P~,
liters
Sanitized Data Stream
Networking
Stacks
Datagrams
Freedom Routing,
Traffic Filter cr~to,
a .
Network Interface
Freedom Traffic
Internet
Figure 2: Freedom Client Internal Architecture
Freedom T"' System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
The interface allows a user to control the operation of the various
components. It creates
and destroys routes in the Freedom System, updates network information,
manages
pseudonymous identities and controls the application and traffic filters.
The network access layer is used to trap an application's networking calls
such as
connect() and sendto() and redirects them to the local application filters.
This allows the
application filter to see the original data stream generated by a network
application and
the response data stream generated by the destination host of the requested
connection.
After the local application filters have processed the data, the networking
calls continue
through the Freedom client host's networking stacks.
The application filters are used to sanitize a network application's data
stream. Many
application protocols such as SMTP and HTTP will reveal information about a
user; the
filters edit or remove this information by parsing the stream according to the
appropriate
protocol and reconstructing a new sanitized stream. As responses arrive from a
remote
host back through the filter, the stream is again processed so that the local
network
application is not aware of the changes that have taken place. This allows the
Freedom
client to implement functionality such as the Cookie Jars and the Ad Manager
without
hindering the operation of the user's applications
After the data stream is returned from the application filter and the network
access layer,
it enters the client host's networking stack. This converts the data stream to
IP, TCP, and
UDP datagrams. Instead of allowing the host to place these datagrams directly
on its
network connection, the datagrams are picked up by the Freedom traffic filter.
This fitter
sanitizes the datagrams by removing the source IP address, TCP and IP
checksums, and
zeroing out other fields. The datagram is then encrypted for the route that
has been
created for the active nym. The encrypted datagram is now sent to the first
Freedom
Server Node in the route. Returning traffic is processed in reverse. Datagrams
are
decrypted according to the route parameters, the headers are reconstructed and
the
traffic filter injects the datagram back into the client host networking
stacks. These are
sent through the application filters and back to the network application. This
method
allows the networking stack on the Freedom client host and the remote
networking stack
to negotiate a connection with each other without being aware that the Freedom
System
is transporting the traffic.
The Freedom Client currently supports the following protocols through its
application
filters:
HTTP: All types of HTTP requests can be sanitized.
~ SMTP: SMTP mail is trapped and sent to the Freedom Mail System.
POP: The POP filter will connect to the user's regular POP server as well as
the
Freedom Mail System. It will automatically decrypt and authenticate Freedom
messages.
~ SSL: The SSL filter is only able to verify that the datastream follows the
SSL protocol.
It cannot decrypt it to verify the contents.
IRC: Basic IRC is supported but DCC is not.
Telnet: In order to speed up performance, telnet is run in line buffer mode in
order to
reduce the number of packets which must be transported. This filter is also
able to
support SSH.
Freedom'"" System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 3
CA 02328548 2000-12-15
NNTP: NNTP is supported for post only. Usenet posts are redirected through the
Freedom Mail System and sent to a commercial news server affiliated with Zero-
Knowledge Systems, Inc. Currently, news must be read from the web.
The Freedom Mail System is closely linked to the SMTP and POP application
filters. On
top of the sanitization work done by these filters, they also encrypt,
decrypt, reconstruct
and scan messages, using the appropriate keys as required by the selected nym.
This
allows the Freedom client to seamlessly integrate a user's preferred mail
application into
the Freedom System.
Masquerading AIP
The Anonymous Internet Proxies (AI Ps) are the core network privacy daemons
that make
up the Freedom Network. They pass encapsulated network packets between
themselves
until they reach an exit node. The masquerading AIP is incorporated into the
Linux kernel
in order to access the kernel's networking features. This allows the AIP to
route large
amounts of network traffic efficiently. A user-level daemon handles
reliability-demanding
operations such as key negotiations.
Freedom
Encrypted Freedom ~der
Traffic
(UDP) AIP Status
Di(fie-Helman updates
exchange
(TCP) NISS
Diffie-Helman
exchange
AIP
NetwoHc Information
queries
Freedom ~ ~ NIQS
Client
Linux
Kernel
Components
Trnacf~pted Freedom
(UDP) , Freedom Putdic signature Key
Server qw~es
; Node Key Query
Server
~ Necanstructed clear
network traffic
. (TCP or UDP)
Internet
Server
Figure 3: Freedom 2.0 Masquerading AlP
Freedom'"' System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 3
CA 02328548 2000-12-15
The Masquerading AIP for release 2.0 has a number of features that set it
apart from the
previous version of the Freedom AIP:
~ The Masquerading AIP does not use fixed packet sizes--it allows variable
packet
sizes. This greatly lowers the bandwidth transport overhead since only
relevant
information is transported.
~ The Masquerading AIP is able to transport some ICMP traffic through the
Freedom
Network. This allows entities communicating through the Freedom Network to
have
better control of their TCP streams.
~ The Masquerading AIPs do not use a network topology. Although a list of
Freedom
server nodes is provided to each AIP, the AIPs are free to connect to any
other AIP
on the network. Although the client is still provided with a topology, it is
now only
used by the client as a guide.
~ The kernel's own networking stack is used to reconstruct traffic going out
to the
Internet. This provides a high level of performance and functionality
~ Bandwidth limiting is available.
~ There is no cover traffic. In order to meet the current security threat
model', cover
traffic is not required. This improves performance by reducing the amount of
"garbage" data on the network and reducing the "throw away" overhead which is
required by an AIP to process a packet.
~ An unauthenticated route allows a client to connect to a number of
predetermined
hosts. This allows the core AIPs to grant access to any of the core servers,
thus
allowing the Freedom core to better load balance incoming connections.
The Masquerading AIP obtains network information from an NIQS server. It uses
the key
query server in order to lookup nym public signature keys which are used to
sign
authenticated route creation requests. The AIP will periodically report its
status to a
Freedom NISS server.
The capacity of the Freedom Network can be scaled up simply by adding new
AIPs.
Since there is no topology, each new AIP can be fully used to support new
users.
Network Information and Reporting
The Freedom System's network information and reporting capability is made up
of nodes
that contain three different components. There is an NISS server to receive
status
updates from server entities in the Freedom System, a network information
database
(NIDB) to store the information, and an NIQS server which mines this database
to answer
network information queries for all entities in the Freedom System. As status
updates
arrive at the Freedom Core, they are replicated and a copy is sent to each
network
information node.
Freedom r~~ System 2.O Architecture
2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
Freedom
Network Network Information
Management Tools
Status
Updates
To Reporting NIQS 1 ~ NIQS 2 ~ NIQS N
Databases
Network Information Requests
(From Freedom clients and servers)
Figure 4: Netlwork Information and Reporting System
The Freedom 2.0 NIQS server adds a number of features that significantly
improve the
speed of a Freedom client's network update and the overall number of Freedom
clients
which can simultaneously query Freedom Network information. These improvements
include:
~ Compressed network description. A new NIQS command returns the entire
network
description in a single response with a single signature. This response is
compressed
and fully downloaded only when it differs from the client's local version of
the network
representation. Although individual entity records can be queried, the Freedom
2.0
client only downloads this compressed information.
~ The NIQS does not provide real time network status. The Freedom 2.0 client
maintains its own statistics on network performance and availability. This
allows it to
provide a more meaningful view of the network to the user. As a result, the
NIQS
Freedom'"" System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
s s a
s s
s , s
, ,
, ,
, s
I I I
CA 02328548 2000-12-15
server no longer needs to provide this information. Instead, the NIQS only
notifies
Freedom clients when a Freedom server is marked as unavailable for system
administration purposes. This reduces the amount of recomputation which must
be
done by the NISS and NIQS since Freedom Network entity records do not need to
be
rebuilt as a result of Freedom server status updates.
~ Reduced client update frequency. Because the Freedom client maintains its
own
statistics on the network, the client's update frequency for Freedom Network
information is greatly reduced. It is currently set to once every 4 hours of
operation.
The Freedom client does not receive realtime status information on the Freedom
Network. Instead, it maintains its own statistics regarding the state of the
network based
on its accesses to it.
Freedom System Entities
Each distinct component type in the Freedom System is known as an entity.
These
entities can be software components, such as an AIP or a nym server, or a data
object,
such as a nym, or a special purpose keyset. The entities are organized into a
hierarchy
that is used to delegate authentication authority. This is further explained
in the Signature
Key Hierarchy section. The NIQS serves description information concerning all
entities
except ZkMaster, FrYear, FrMonth, and Nym.
Most entities have both a signature key pair and a cryption key pair. In some
cases
however, only one type of key pair is used by the entity.
ZkMaster This entity is used by the Zero-Knowledge master key for the Freedom
System. The public component of this key is hardwired into every piece
of Freedom software.
FrYear This is the Zero-Knowledge Freedom yearly key. Once per year this key
is used to sign all keys below it in the hierarchy.
FrMonth This is the Zero-Knowledge Freedom monthly key. Once per month this
key is used to sign all keys below it in the hierarchy.
TokSrv This is the token server entity.
NymSrv This is the nym server entity.
Niqs This is the NIQS server entity.
Niss This is the NISS server entity.
Nmta The NMTA is the mail system server which processes mail sent from a
nym and arriving at the Freedom System core.
Imep The IMEP is the mail system server which processes mail sent from an
Freedom'"" System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. ~ Z
CA 02328548 2000-12-15
Internet user to a nym and arriving at the Freedom System core.
Pop Pop server entities can be accessed by nyms in order to download their
mail.
KeyQry This is the key query server entity.
Nym This is the entity used for all nyms in the Freedom System regardless of
the actual type of the nym.
PKI Systems
The PKI servers consist of three types of server, a key query server, a nym
server, and
token server. A nym server is used to create and manage a Freedom client
user's
pseudonymous identities. A key query server is used to provide public keys on
request to
Freedom servers and clients. The token server provides nym creation tokens,
which
allow a user to anonymously create nyms without identifying their real
identity.
The basic architecture is shown in the diagram below. The Key Query Server
provides
access to public signature and cryption keys for all entities on the Freedom
Network. It is
used by all entities in order to validate signatures and keys that they
receive in the course
of their activities.
Freedom T~~ System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. ~ 3
CA 02328548 2000-12-15
PKI Database
Management Tools
Nym Activation Code
Dah~baso ~ ~ Database
Token
Server
Nym Management Public Key Lookup Token Generation
Requesb Requesb Requesb
(From Freedom Clients) (From Freedom slienb (From Freedom Clients)
and servers)
Figure 5: Freedom 2.0 PKI Subsystems
Signature Key Hierarchy
The key query server provides signed public keys in response to requests from
various
Freedom entities. These responses are signed following a hierarchy that
ultimately allows
a Freedom client to authenticate them.
There is a set of keys at the top of the hierarchy which are used only for
signing. These
keys include the Master, Yearly, and Monthly keys. The Monthly key signs the
signature
keys for all of the Freedom System's servers.. There is a Master key, whose
public
parameters are encoded into all Freedom software for reference. The Master key
is a
2048 bit DSA key, using the same prime parameters as are used in PGP. The
Master
Key signs a Yearly key. The Yearly key is 1024 bit DSA; it is used to sign the
Monthly key
and client software updates.
Each Freedom server entity signs its own public cryption key using its private
signature
key. The NymSrv key also signs the Nym signature keys. The Monthly key, and
the keys
it signs, are stored online.
Freedom T~~ System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
s s v s s
v s a s s
s s a s s
s s ~ s s
a a ~ s s
i i i i i
CA 02328548 2000-12-15
The nym server provides a way for clients to create and manage pseudonymous
identities. It functions as a nym directory service for the Freedom System.
The token
server allows the Freedom client to redeem an activation code for a set of nym
creation
and upgrade tokens. This allows pseudonymous identity creation to occur
without being
able to track a nym back to the originally purchased activation code. For
details on this
process, please refer to the paper "Untraceable Nym Creation on the Freedom
2.0
Network"°. A nym can be revoked by deleting its keys from the public
key databases. This
makes a nym unable to use the system within a few hours as cached copies of
its keys
expire in the AIP key caches. These caches set a TTL of a few hours on each
public nym
signature key.
The Freedom System supports multiple types of nyms, each with different
capabilities.
These nyms are identified by a type number which implies a certain set of
capabilities
common to all nyms of that type. These capabilities can be arbitrarily
changed. The ability
to upgrade from one nym type to another is currently disabled.
Type 1 These are the full access nyms which are offered by the Freedom System.
These currently have access to all of the system's capabilities, including the
mail system, authenticated and unauthenticated route creation.
Type 2 These nyms are present in the Freedom System but are currently not
distributed to users. Type 2 nyms are defined so as to only be able to access
Freedom r~~ System 2.O Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
Figure 6: Key Hierarchy
CA 02328548 2000-12-15
the Freedom Mail System. They are able to create unauthenticated routes in
order to access the Freedom core systems to send and download mail. These
nyms have a set of public signature and cryption keys in order to properly
sign
and encrypt messages. They are, however, unable to create authenticated
routes on the Freedom Network. They cannot therefore access sites on the
Internet.
Type 3 Type 3 nyms are created in the Freedom System. However, they can do
nothing other than nym management operations on the nym server and
create unauthenticated routes to the Freedom System core. These nyms exist
to allow a user to reserve an entry in the nym namespace and to facilitate the
use of certain Freedom client features such as cookie management, the form
filler, ad manager, and the personal firewall. These nyms are not able to
create authenticated routes on the Freedom Network.
The token server is used to redeem activation codes for nym creation and
upgrade
tokens. This transaction is done anonymously through the Freedom Network. This
layer
of indirection in the nym creation process ensures that a nym cannot be
tracked back to
its owner when it is created.
The PKI systems interact with most other components of the Freedom System. AI
Ps
lookup public signature keys for nyms that sign route creation requests. The
nym server
creates mail access certificates that are returned to the client and are in
turn passed to
the mail system to create nym mail accounts. The Freedom client uses the nym
server to
create and modify new nyms. The PKI servers themselves obtain network
information
from the network information system's NIQS server and report their status to
the NISS
Database Systems
The Freedom databases are accessed through the PKI and Network information
servers.
Any response generated by one of these servers will always be signed by the
server's
signature key.
Nym Database
The nym database holds all publicly available information that describes each
nym. None
of the stored information identifies the true identity of a nym owner. This
database can be
queried by anyone, but only the owner of a nym is allowed to modify a nym
record. When
a nym is created, that entry in the nym name space becomes permanent. If the
owner of
a nym decides to destroy their nym, or the nym expires, that nym name is not
returned to
the name space and it cannot be used by another Freedom user.
Public Keys
The public key database holds the public signature and cryption keys for all
entities in the
Freedom System, including nyms and servers. All keys are stored signed,
according to
the Freedom key hierarchy. When a public key lookup is made by a Freedom
entity, it
needs to lookup the keys used to sign the request key in order to verify the
validity of the
Freedom r"' System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
response. These extra keys are cached by the requesting entity in order to
reduce extra
key lookups.
SpentTokens
The spent token database is used to prevent a nym creation or upgrade token
from being
reused. When an attempt to spend a token at a nym server is made, the database
is
searched for a hash of the token. If it is found, the token has already been
used and is
therefore refused. If it is not found, the hash is stored in the database and
the token is
accepted. The hash of the token is not linked to any other piece of
information.
Activation Code Database
The activation code database is used by the token server to keep track of
activation
codes which can currently be redeemed by users. Each activation code has an
associated capability code which is used to determine the type and number of
tokens
which are generated when the activation code is redeemed. There is no token
database.
These are generated and signed as required by the token server.
Network Information Database (NIDB)
This database maintains information regarding all Freedom server entities. An
entity
record can be queried independently, or a complete compressed description of
the entire
network can be queried.
Reporting Database
This database is maintained by the NISS using the status updates which are
sent to it
from the various Freedom servers. It keeps track of things such as the uptime
of each
server, the number of bytes transfered, the number of messages processed, etc.
This
database is used to manage the Freedom System.
Mail System
The Freedom mail system handles all mail sent to and by nyms. It uses the
Freedom
Network to anonymously deliver mail messages and uses a POP box in the Freedom
Core to store mail which is to be read by nyms.
The POP mail system completely replaces Freedom's original Reply Block based
mail
system. Where possible, the design reuses proven and existing technology,
generated
both internally and externally of Zero-Knowledge Systems, rather than
designing and
implementing our own custom solution set.
The design for the POP mail solution is based on qmails, an open and freely
available
software suite which has gained popularity as the basis for reliable, high
pertormance
systems. qmail is a highly modular software solution. The new mail system
design and
implementation embraces this philosophy; each of the subcomponents which are
needed
in order to modify a stock qmail installation to the purposes of the Freedom
Network is a
small, loosely coupled, and crisply defined unit of functionality. The
assembly and
integration of these units form the functionally complete mail system.
Freedom r"' System 2.O Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
Freedom
Client
Freedom
Network
Zero-Knowledge
Mail System Core
Freedom Core
Server AIP
Node
Nym downloads encrypted Nym uploads encrypted
mail via POP through an mail via SMTP through an
unauthenticated route unauthenticated route
Freedom ~-~-
NMTA
POP Server Freedom
Marl NMTA
POP ~
anym backend
Store
Mail
to
an
Internet
User
via
QMQP
Error
Message
sent NgWS
back
to
an
Internet
User Server
IMEP
IMEP
backend Relay
Mail from an Mail to an
Inlenxt User ( Internet User
via SMTP via SMTP
Internet
User
Figure 7: Freedom 2.0 Mail System
There are three new entity types for the mail system: POP, IMEP, and NMTA. The
POP
entity is the Freedom POP server that is accessed via the local pop proxy on a
Freedom
client when it wishes to download a nym's mail. The NMTA (Nym Mail Transfer
Agent)
Freedom r~" System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
entity is used to process mail from a nym. The IMEP (Internet Mail Encryption
Proxy) is
used to process mail from an Internet user to a nym. The IMEP and NMTA are
essentially
queuing mechanisms used to grab mail messages. The IMEP and NMTA backends
consist of a series of filters used to process the mail. Some of these filters
are:
Authentication
Programs and libraries to provide authentication services to the mail system
such that the
PKI system can provide nyms with information that they can use to authenticate
themselves to the system. Included in this is proper handling of nyms that
have had their
privileges revoked.
Bounce Handler
Bounce notifications resulting from failed deliveries have to be delivered to
the sender
such that the notice is meaningful.
Internet Block List Enforcer
Do not deliver mail to an Internet address that has specifically requested not
to receive
mail from a particular nym.
Mail2News Gateway
Route mail destined for newsgroups to the appropriate place, respecting our
cross-
posting constraints and sending limits.
Mail Encryption "Server"
A distributable service to perform encryption and processing of Internet to
nym mail.
Mail Sending Limif Enforcer
Make sure that a nym does not exceed the daily allowance of mail that It is
allowed to
send.
Mail Store Quota Enforcer
Make sure that a nym's POP storage usage does not exceed its maximum allocated
disk
space.
Nym Block List Enforcer
Do not deliver mail to a nym that has specifically requested not to receive
mail from a
particular sender.
Spam Control
Insert spam control software into the delivery pipeline so that nyms which
turn on our
spam control features have several spam filters applied to their incoming
mail.
Statisfics Engine
Gather and process various statistics on mail system usage and load in order
to facilitate
system tuning and analysis.
Freedom r~~ System 2.O Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
CA 02328548 2000-12-15
Tagline lnserter
Insert tagline text into messages to Internet addresses (that is, nym to non-
nym email).
This is currently not implemented.
The mail system needs to query nym public cryption and signature keys for
encrypting
and authenticating mail messages. Management of nym account parameters is done
through special messages to the mail system itself so there is no dependency
on the nym
server. Client access to the mail system is done through unauthenticated
routes through
core AIPs. The mail system, however, is not dependent on this.
Script Server
The Freedom Script Server is an external HTTP server that is run by Zero-
Knowledge. It
provides the Freedom client with the scripts that allow the Form Filler
feature to
automatically complete online forms what can be found on various websites. It
also
provides the rules for the Ad Manager feature, which are used when the Freedom
client's
ad management capability is enabled.
These scripts and rules are regularly updated by Zero-Knowledge systems and
signed by
NIQS entity key called NIQS/ScriptServer. The client queries the server on
startup and
downloads the latest update. If this server is not available, the client will
continue to
function but will not be able to automatically adapt to new advertising
strategies and to
new forms. It will merely use the scripts and rules that it currently has in
its database.
This server is used only by the Freedom 2.0 client, it is independent of the
Freedom
Network. The core servers and AIPs are not aware of its presence, nor does it
have an
associated entity type.
Conclusion
Every effort has been made to make Freedom the most integrated, strongest and
easiest-to-use privacy system available, and we believe we have achieved this
goal. No
system is completely infallible, however, but this white paper, in conjunction
with
"Freedom 2.0 Security Issues and Analysis"6, will show the reader the extent
to which the
system is secure under ordinary, and even extraordinary circumstances. We
maintain a
policy of full disclosure of the system's workings and weaknesses in an effort
to be up-
front and honest to the community of Freedom users and interested parties.
Glossary
Freedom Zero-Knowledge's online privacy suite. Using a client-server
architecture, Freedom provides total privacy to Internet users.
Freedom works transparently with current Internet applications. When
using Freedom's premium services, Internet traffic is encrypted before
leaving the user's computer and routed through private connections.
Freedom'"' System 2.0 Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved. 5~
CA 02328548 2000-12-15
Nym A pseudonymous digital identity. Nyms exist in cyberspace exactly the
same way as regular online identities, without revealing the identity of
the real-world person. Nyms are active, inactive, or expired. Inactive
nyms can be reactivated or deleted. Expired nyms are removed from
the Freedom Nym Server and are not available to any other Freedom
user.
Private Key One of two keys used in private/public (asymmetric) key
cryptography.
Users receive messages encrypted with their public key and decrypt
them using their secret private key. The private key can also be used
to digitally "sign" a message, ensuring the authenticity of the sender.
When someone uses their private key to sign a message, they encrypt
a portion of the original message that the recipient decrypts using the
sender's public key. If the public key decrypts the scrambled portion of
the message, the recipient knows that the sender is who they claim to
be.
Private/public key cryptography is the more flexible of the two main
encryption types (the other being symmetric key) because the key
used to encrypt a message is available to all, but only one person
holds the private key (key management is easier than with symmetric
encryption). Ensuring the secrecy of the private key is easier when it
does not have to be distributed, as is the case for symmetric
encryption.
Public Key One of two keys used in private/public (asymmetric) key
cryptography.
Users release their public key, which is used to encrypt messages that
can only be decrypted using the user's private key. Private/public key
cryptography is the more flexible of the two main encryption types (the
other being symmetric key) because the key used to encrypt a
message is available to all.
Ensuring the secrecy of the private key is easier when it does not have
to be distributed, as is the case for symmetric encryption.
Symmetric An encryption system, where the person encrypting the message uses
Encryption the same key as the person decrypting the message. Key
management and secrecy is paramount to maintaining the integrity of
the encrypted data. If the key is compromised or shared, anyone could
encrypt and decrypt messages.
Sender and receiver must be properly coordinated to ensure that the
correct key is used in order to have secure communications. Also
called secret-key, single-key, and one-key encryption.
Freedom r'" System 2.O Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
1 '
CA 02328548 2000-12-15
Acknowledgements
The authors of this document would like to thank everyone in the Zero-
Knowledge
Engineering and Development teams for their valuable contributions. Their
input and
feedback helped to make this document a reality.
Endnotes
' "Freedom Network 1.0 Architecture", Ian Goldberg, Adam Shostack, Zero-
Knowledge
Systems, Inc. http:flwww.freedom.net/infolfreedompaperslFreedom-
Architecture.pdf
"Freedom 2.0 System Protocols", Philippe Boucher, Ian Goldberg, Adam Shostack,
Zero-Knowledge Systems Inc. Not yet published as of this publication date.
' "Freedom 2.0 Threat Model" Not yet published as of this publication date.
' "Untraceable Nym Creation on the Freedom 2.0 Network", Russell Samuels, Ed
Hawco,
Zero-Knowledge Systems Inc.
qmail D. J. Bernstein http:/fwww.qmail.org/
6 "Freedom 2.0 Security Issues and Analysis", Adam Back, Ian Goldberg, Adam
Shostack, Zero-Knowledge Systems Inc.
Freedom r"~ System 2.O Architecture
~ 2000 Zero-Knowledge Systems Inc. All rights reserved.
