[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[freehaven-cvs] Begin merge of attacks and security.



Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv16741

Modified Files:
	pynchon.tex 
Log Message:
Begin merge of attacks and security.



Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -d -r1.47 -r1.48
--- pynchon.tex	18 Sep 2004 00:37:32 -0000	1.47
+++ pynchon.tex	18 Sep 2004 01:00:05 -0000	1.48
@@ -134,18 +134,18 @@
 our users.
 
 \subsubsection{In this paper}
-We begin in section~\ref{sec:background} with a discussion of related work,
+We begin in Section~\ref{sec:background} with a discussion of related work,
 and an overview of known attacks against existing pseudonymity systems.  (To
-motivate our work, subsection~\ref{subsec:disclosure} presents new analysis
+motivate our work, Subsection~\ref{subsec:disclosure} presents new analysis
 on the effectiveness of passive traffic analysis against current reply-block
 based nym servers.)  Section~\ref{sec:design} presents the Pynchon Gate in
 more detail, describing its organization, design rationales, and network
 formats.  We describe our simple distributed trust PIR protocol in
-subsection~\ref{subsec:protocol-design}.  In section~\ref{sec:security} we
-analyze security, and in section~\ref{sec:performance} we discuss
+subsection~\ref{subsec:protocol-design}.  In Section~\ref{sec:security} we
+analyze security, and in Section~\ref{sec:performance} we discuss
 optimizations and compare our performance to that of other pseudonymous
 message systems.)  We close with an evaluation of our success in
-section~\ref{sec:conclusions}.
+Section~\ref{sec:conclusions}.
 
 \section{Background and attacks}
 \label{sec:background}
@@ -286,7 +286,7 @@
 %anonymity strength of the system also increases)
 each user's bandwidth requirements become prohibitive.
 Users are thus encouraged to ``cheat'' and only download
-sections of the newsgroup that they are sure contain their messages, or
+Sections of the newsgroup that they are sure contain their messages, or
 not download on days that they do not expect messages. This allows an
 attacker to gather information about messages in which an individual has
 interest, and provides a way to attack the security of the
@@ -305,26 +305,62 @@
 information about nym holders. Systems should be designed so that such
 information cannot be obtained.
 
+The Pynchon Gate protects against these attacks by using encryption keys
+for the nym accounts to encrypt incoming messages. Nym holders do not
+communicate directly with the nym server, and the nym server is not
+entrusted with any identifying information for the user. All data in the
+tree structure is deleted from the collator after being passed to the
+distributors. This ensures that the collator has as little information
+useful to an attacker as possible, and that collator resource requirements
+are kept low.
+
 \subsubsection{Mix attacks.} 
 Systems based on the mix-net primative must be concerned with attacks
 against the underlying mix-network, as they rely upon it for security.
 Additionally, reply-block-based nym server systems require additional
 security properties that normal mix-net systems may not have~\cite{minx}.
 
+The Pynchon Gate uses mix-nets for forward message delivery only. Attacks
+which do not work against a mix-net in normal forward-delivery mode will
+not impact Pynchon Gate.
+
 \subsubsection{Replay attacks.}
 An attacker capable of monitoring the communications network may attempt
 to obtain information about nym holders by comparing network and user
 behavior when a given message or packet is transmitted multiple times.
 
+The Pynchon Gate uses TLS when communicating between components and the
+client, so that data is encrypted with a short-lived session key. The
+topology of the Pynchon Gate infrastructure further eliminates areas of
+potential replay attack risk.
+
 \subsubsection{Tagging and known-cleartext attacks.} An attacker may alter
 a message, or observe the cleartext of a message, so that he may be able
 to later link an input message with a given output retrieved by the
 nym holder.
 
-\subsubsection{{\it Who am I?} attack.} 
+The Pynchon Gate's message and link encryption prevents an attacker from
+observing the cleartext of a message. Tagging attacks are ineffective, as
+the data transfered to the user from the distributors appears random. The
+metaindex provides the client with the hash of the index bucket. Each
+message bucket provides the hash of the next message bucket, and with this
+information, the client can verify the integrity of information downloaded
+from distributors and respond to garbled data without leaking information
+about which bucket it was requesting.
+
+\subsubsection{"{\it Who am I?}" attack.} 
 An attacker may send messages intended for nym Alice to nym Bob instead,
 to confirm that Alice and Bob are the same nym holder~\cite{gd-thesis}.
 
+This attack relies primarily upon the ability to link one nym, $Alice_1$,
+with another nym, $Alice_2$, by sending a message encrypted with
+$Alice_1$'s reply block to $Alice_2$'s address. The architecture of
+Pynchon by the nature of its design avoids this, though a similar social
+engineering attack may be performed if the nym holder is using a separate
+message encryption protocol such as PGP~\cite{rfc-2440}. More research
+needs to be done in the area of privacy-preserving human-computer
+interaction.
+
 % Also: social engineering; traffic analysis; leave/join attacks...
 
 \subsubsection{Usage pattern and intersection attacks.}
@@ -344,9 +380,38 @@
 nym holder's reply-block path, and increase his chances of successfully
 linking the nym with the nym holder's true name.
 
+Users of the Pynchon Gate select distributors from which to receive data
+at random, each time the nym holder retrieves her messages. As opposed to
+systems where the pseudonym infrastructure initiates the delivery of
+messages, the Pynchon Gate Client initiates the retrival of messages, and
+thus message retrieval cannot be correlated to a given nym by a malicious
+sender. 
+
+Message buckets are of a fixed size, to protect against attacks similar to
+the active flooding attacks on mix-net systems~\cite {trickle02} as well
+as simple usage pattern analysis. Delivery of excess messages for a given
+nym account may be conducted by \emph{trickling} the pending messages to
+the distributors over the next several tree distributions. If a client
+will be retrieving large amounts of data on a regular basis, this method
+will not work. Instead, the client should at account creation time request
+a sufficient number of buckets to receive all data destined to it. Pending
+data queued on the collator should be expired after a reasonable amount of
+time.
+
+A hash tree of variable depth would risk leaking usage information about
+nym-holders. The Pynchon Gate uses a tree of a fixed depth.
+
+Since the time between the delivery of a message to the nym server and a
+reply from the nym holder may leak information about the nym holder to an
+observer, traffic from the client to the distributors is regulated by the
+client, which queries the distributors only at given intervals. The
+intervals chosen are random within the message window, to thwart active
+attacks against the distributor targetting a specific client.
+%XXXX Fix this in design.
+
 \subsection{Statistical disclosure against reply-block-based nym servers}
 \label{subsec:disclosure}
-Nym servers based on reply blocks (discussed in section
+Nym servers based on reply blocks (discussed in Section
 \ref{subsec:related-work} above) are currently the most popular option for
 receiving messages pseudonymously.  Nevertheless, they are especially
 vulnerable to end-to-end traffic analysis.
@@ -406,7 +471,7 @@
 \section{The Pynchon Gate Design}
 \label{sec:design}
 We present a design framework for The Pynchon Gate. A detailed
-implementation spec can be found in~\cite{pynchon-spec}.
+implementation specification can be found in~\cite{pynchon-spec}.
 
 \subsection{Overview and Rationale}
 The Pynchon Gate is a group of servers that provide anonymous message
@@ -425,7 +490,7 @@
 a collator, which
 batches them into an indexed ``bucket pool,'' and
 and passes these pools to each independently operated distributor node in
-the network.  Pseudonym owners then make a series
+the network.  A Pseudonym holder then makes a series
 of requests to $k$ chosen distributor nodes, enabling her to receive her
 messages without the individual distributors determining the identity of the
 pseudonym being requested. The protocol used is resistant to collusion:
@@ -651,12 +716,12 @@
 \label{sec:security}
 As with any anonymity system, care must be taken at all steps to prevent
 possible attacks on the effective anonymity provided.
-
-In order to protect against usage pattern attacks, it is imperative that
-the tree depth be the same for all leaf nodes.
+%
+%In order to protect against usage pattern attacks, it is imperative that
+%the tree depth be the same for all leaf nodes.
 
 The collator is responsible for publishing tree metadata. This metadata
-includes the depth of the tree, the individual size of each bucket, the
+includes the individual size of each bucket, the
 total number of buckets, and a hash tree root which can be used to verify
 the integrity of any bucket individually. Clients must obtain this
 information before initiating the message retrieval protocol with the
@@ -775,7 +840,7 @@
 %Describe the derivation of each value.
 
 We have evaluated the resource requirements of various nym server systems
-described in section~\ref{subsec:related-work}, and compare their
+described in Section~\ref{subsec:related-work}, and compare their
 respective performance in figure~\ref{fig:performance}. Bandwidth
 requirements for the independent
 components of the pseudonym system are averages per cycle. We use the term

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/