CA2328548A1 - Privacy system - Google Patents

Abstract

This white paper, targeted at the technically knowledgeable user, looks at the entities, protocols, and systems that make up the Freedom Network Mail System. More extensive documentation, containing implementation details with the intent of allowing and encouraging external cryptanalysis of the system will be available at some point in the future.

Description

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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 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 =

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 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 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 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.

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.

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 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 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 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 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 ~ 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 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 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 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 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.

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 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 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 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 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 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 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.

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.

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.

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

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.

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 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 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.

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

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

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 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 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 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.

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.

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.

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.

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~

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 ' 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.

Claims