[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] First draft of a description of remailer pingers.
Update of /home2/freehaven/cvsroot/doc/pingers
In directory moria:/tmp/cvs-serv17033
Added Files:
pingers.tex
Log Message:
First draft of a description of remailer pingers.
--- NEW FILE: pingers.tex ---
\documentclass[runningheads]{llncs}
\usepackage{epsfig}
\usepackage{latexsym}
\usepackage{psfrag}
\usepackage{amsfonts}
\title{Measuring Remailer Reliability}
\author{Len Sassaman\inst{1}}
%foo
\institute{Katholieke Universiteit Leuven \\
Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium
\email{\{len.sassaman\}@esat.kuleuven.be}
%foo
\bibliographystyle{alpha}
\date{}
\begin{document}
\maketitle
\begin{abstract}
In a network of distributed mix-net servers, information regarding the
network health and operational behavior of the individual nodes must be
made available to the client applications which generate messages for use
in the mix-network. We present a summary of the techniques currently in
use, and evaluate their methods.
We evaluate the security concerns regarding an information service, including
the issues regarding anonymity set preservation, information disclosure, and
node cheating.
\end{abstract}
\section{Introduction}
Chaum~\cite{chaum-1981} introduced the concept of mixes as a method of
providing secure anonymous communication. The publicly accessible mix
networks~\cite{}, operated by volunteers, are prone to intermittent
failure of individual nodes. It is therefore necessary for mix client
software to have an accurate view of the health of the nodes in the mix
network. This information is gathered by sending test messages through
each node, and observing the success or failure of the mix to successfully
transmit the message. In a similar fashion, links between mixes are
examined by sending messages through every combination of two consequtive
mixes. Since the overhead and operational complexity involved in
monitoring an entire network of mixes is too great for the average user,
\emph{pingers} perform this function, and provide their results for
download by the mix clients. Pingers track additional information as well,
such as the average latency provided by each mix, changes in the key
information and capabilities of the mixes, and so forth.
\section{Prior work}
\label{pingers}
\subsection{Raphs-pinger}
Raph Levien first first introduced the concept of monitoring service for
anonymous remailers was designed to work with the Cypherpunk "Type 1"
remailer network. FIXME (Details of Raph's basic info gathering scheme)
\subsection{Echolot}
Echolot is the most widely used pinger for the Types 1 and 2 remailer
networks. As of this writing, there are nineteen Echolot pingers in
operating publicly~\cite{allpingers}.
\subsubsection{Echolot algorithm}
In order to test remailer A's reliability, Echolot sends an encrypted ping
through a 1-hop chain every two hours. Pings are not sent strictly at
02:00, 04:00 etc, but at 2h*n + f(A, date) % 2h. ( f() is a function of
the remailer name and the date of the current day (basically md5)). This
is to prevent the mixes in the network from being overwhelmed with
connections from pingers at regular intervals.
We record the timestamp for each outgoing ping, and we record the time it
took to return for incoming pings.
The reliability of a node is the result of received/sent, with the
following weighting applied:
weight := w1 * w2;
w1 is a function of a ping's age:
age: 1 2 3 4 5 6 7 8 9 10 11 12 [days]
weight 0.5 1.0 1.0 1.0 1.0 0.9 0.8 0.5 0.3 0.2 0.2 0.1
age is how long ago the ping was sent. So if a ping was sent 23
hour ago, it weighs 0.5, if it was sent 2 days ago, its weight is 1.
Approaching 12 days, the weight approaches 0.0.
w2 also considers this node's pings' latencies over the last 12 days:
for pings that already returned, w2 is 1.0.
otherwise:
Let mod_age := (now - sent - 15m) * 0.8
w2 is the fraction of pings returned within mod_age seconds.
Example:
Assume a ping was sent 2 hours ago. mod_age is 84 minutes. If 100%
of this node's pings were faster than 84 minutes, then w2 = 1. If
only 30% were received within 84 minutes of sending out the ping,
then w2 is 0.3, If no ping was ever faster than 84 minutes, then w2
is 0.
The reported latency is the median of all received pings of the last 12
days.
Chain pings are done in a similar fashion: We ping two-hop chains A, B.
Each chain is pinged once a week (with a similar offset function as
above).
"Interesting chains" are pinged more often - daily.
We report chains as broken if
- we sent at least 3 pings
AND
- received/sent <= rel(A) * rel(B) * 0.3.
rel(X) is remailer X's reliability in single-hop pings.
We define interesting chains as chains
- where we sent less than 3 pings, without getting any back.
OR
- where received/sent <= rel(A) * rel(B) * 0.3 (i.e. the chain is
reported broken)
\subsection{Mixminion directory server}
Mixminion~\cite{mixminion} generalized the concept of pingers, defining a
directory server component of the Mixminion system, responsible for the
distribution of all information about remailer availability, performance,
and key material. The designers of the Mixminion system considered the
attacks on the independent pinger model, and specified that directory
servers be synchronized as well as redundant.
Mixminion publishes signed \emph{capability blocks} in the directory
server, consisting of the supported mix protocol versions, mix's address,
long-term (signing) public key, short-term (message decryption) public
key, remixing capability, and batching strategy.
%FIXME [Does Mixminion have any details on calculation stategy? Not sure,
%but I should check the source.]
\section{Gaming the data}
A mix which is otherwise honest (in that it correctly performs mixing
duties without breaking the anonymity of the messages transmitted through
it) may attempt to convince a pinger to provide false information
regarding the performance of the mix, by identifying the source address of
pings, and treating the pinger messages differently than normal messages.
While this manipulation will not change basical results such as the
operational status of a defunct mix, it could allow a mix to alter the
latency statistics reported for its operation. Some
pingers~\cite{pingstats} attempt to discourage such cheating by creating
ping messages which originate and terminate at a local mix which also
mixes normal messages, so that the target mix cannot distinguish between
user messages and pinger messages. Unfortunately, systems such as
Mixmaster have a minimum distance between hops which is considered when
creating a mix chain, and thus messages which consist of the mix chain
A,B,A will still be distinguishable as pinger messages, since no properly
functioning mix client would generate this chain. If a pinger were to
create a chain of A,B,C,A, neither mixes B or C would be able to tell that
the message contained pinger information, but the results would only
indicate the combined latency of the mixes B and C, as well as the health
of both B and C and the link between those mixes. It would not provide any
useful information about B or C alone.
The pinger message data (or \emph{pings}) itself should not be
deterministic, lest a mix attempt to "back-fill" the results for pings
sent during a period when the mix was offline.
\section{Anonymity set attacks based on pinger data}
A mix network in which users obtain their view of the network's heath and
status from multiple independent sources opens the system to partitioning
attacks~\cite{} against the users, based on differences in the mix
selection based on the results of the different pingers. In a system of
entirely honest pingers, this attack is feasible for an adversary
operating in the passive observer model.
Suppose Alice retrieved her network health information from pinger 1, and
Bob retrieved his information from pinger 2. An observer watching the
network local to Alice or Bob would know which pinger the user under
observation cose. If the information provided by both pingers differend in
some manner, the delta would contain mixes that, if chosen by Alice or
Bob, would betray which pinger had been used to obtain this information. A
message processed by a mix contained only in the results provided by
pinger 1 could not have been sent by Bob, who obtains his results from a
pinger lacking that information.
Additionally, differences in pinger results for mix latency could lead to
more subtle variations in mix path selection, which may aid an attacker.
If a pinger is operated by an attacker, it becomes possible to
specifically target individual users by providing them with unique
information about the network, in order to partition them into an
anonymity set of size 1. Users can attempt to prevent against this attack
by obtaining their pinger results from a widely-published location, such
as Usenet, though this does not completely solve the partitioning attack
problem, and introduces additional reliability constraints on the quality
of the pinger information.
\section{Unified directory view}
The solution to the partitioning attacks mentioned in the previous section
involves providing all clients with the same view of the network. Each
pinger should calculate its results for the status of the network, and
compare these results with those of the other pingers. The pingers then
must agree on a compromise result which reflects an accurate view of mix
availability, and provides every client with a consistent information with
which to calculate message paths.
%[FIXME Klaus's protocol goes here]
\section{Conclusions and future work}
\label{conclusions}
\subsection*{Acknowledgments}
\end{document}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe freehaven-cvs in the body. http://freehaven.net/