\documentstyle[twoside, fancyheadings, doublespace, fullpage, epsf]{article}
\setstretch{1.5}
\textheight 8.8 in

\lhead{Michael Freedman ({\it mfreed@mit.edu}) \\
David Molnar ({\it dmolnar@hcs.harvard.edu})}
\rhead{Free Haven Project:  Threat Model and Attacks \\
\today}

\begin{document}

\pagestyle{fancy}
\pagenumbering{arabic}


\section{What This Is}

This document describes the threat model for the Free Haven project. 
It states the security goals of the Free Haven system, and then describes
classes of adversaries according to their motivation and capabilities. 
Specific attacks against the system are discussed, along with some
possible countermeasures. 

\section{Security Goals and Failure Modes}

This section is more or less taken from Roger Dingledine's definition
of anonymity circulated on the freehaven-dev list and expanded a bit. 

Free Haven is a distributed storage system with these goals :
\begin{itemize}

\item Anonymity

\item Integrity 

\end{itemize}




\section{Adversaries and Their Goals}

Global failure - the system is unusable

Local failure - one node gets screwed. 


\section{Adversary Capabilities and Specific Attacks}

Please note that attacks and exploits are listed in plain-text.
Some possible solutions follow attacks in {\it italics}.



\subsection{Servnet Node Adversaries}

These adversaries try to take control of the node itself. Communication
to and from other nodes gets through, but is no longer following protocol. 

\subsubsection{Active}

\begin{itemize}


\item Exploit trust model:

\begin{itemize}
\item Gain trust quickly:  Trust \\
{\it Users have the planned ability to weight storage size versus
duration accordingly to their needs.  Systems in which size is
relatively important in relation to trust might quickly gain trust in
adversaries with large storage capacities.}
%Current concept of storage is in Meg-Months.  Change trust weight
%to $(size)*(n*time)$, where $n$ is some constant which tells how much 
%more to weight time over size.  Assumption:  10 gig storage for a 1000
%days is preferable to 1 terabyte for a 10 days.}
\end{itemize}

\item Access to share DB:
\begin{itemize}
\item Change number of failed attempts:  System Integrity
\item Change last known buddy location:  Trust, System Integrity \\
{\it Target responds ``I never had it'' - trust db comparison.}
\item Change size of share (how many required to reconstruct):  System
Integrity  \\
{\it Compare information with buddy.  Unlikely both will be modified.}
\item Change public key of signer:  System Integrity \\
Share no longer verifiable.  Similar attack to dropping share, except
much harder to pin blame. \\
{\it Rely on other means to reclaim:  presense of buddy, robust
information dispersal algorithm.  Alternatively:  trading protocol
includes verifying share signature upon receiving file.  Broadcast that
signature bad when found.}
\end{itemize}

\item Make up receipts:  Trust \\
{\it Receipts signed with private key}

\item Make Data Unrecoverable:
\begin{itemize}
\item Destroy received share: System Integrity
\item Ignore get requests for shares: System Integrity
\item Content-specific share destruction:  System Integrity \\
Trade constantly for a specific share.  Then drop it.  Worse,
continually trade for a number of shares that are used to reconstruct
a specific file, then attempt to destroy enough of them to make the
entire file unrecoverable.  \\
{\it If node is very choosy about what it will trade for, other nodes
do not seek to trade with it as much.}
\end{itemize}
{\it All of these attacks are similar:  shares appear lost in the
system.  We rely on our robust information dispersal algorithm to still
be able to reconstruct share.  Also, the node's trust will diminish with
repeated attacks as such.}

\item False broadcast messages:
\begin{itemize}
\item Dropped share: Trust \\
{\it Target responds with negative}
\item Target lost buddy: Trust \\
{\it Target responds with negative}
\item Target is bad trading partner:  Trust \\
{\it Target responds with negative.  These last three attacks }
\item Flood servnet with messages: DoS \\
Generally, only some subset of servnet wants to make itself explicitly
public.  However, any node that has existed on servnet for a while will
learn its geography, and thus be able to flood mixnet with messages to
all the nodes. 
\end{itemize}

\item Marking attack: Anonymity \\
Given a specific reply block to different persistent IDs, be able to
determine which messages come from that ID, given a different final hop.

\end{itemize}


\subsubsection{Passive}

\begin{itemize}
\item Access to encrypted messages:
\begin{itemize}
\item Reply headers:  Anonymity
\item Actual message:  Anonymity
\end{itemize}

\item Make Data Unrecoverable:
\begin{itemize}
\item Go offline:  System Integrity
\item Lose shares:  System Integrity
\end{itemize}
{\it Robust information dispersal and recovery.  Node loses trust.}

\item Attempt to reconstruct everything known

\item Content-biased:
\begin{itemize}
\item Check for ``bad'' data:  System Goals, Secrecy
\item Try to share ``bad'' data away:  System Goals, Secrecy
\end{itemize}
Both of these passive attacks move away from the content-unbiased
concept of FreeHaven that we are trying to develop.  Not only is this
somewhat counter to one of the goals/design motivations, but an edge
adversary might gain some information from such via traffic analysis.
If a node is known to dislike certain content-types, then refusals to
trade or quickly trading certain shares suggests that these shares have
a certain content. \\
{\it If a node is very choosy during trades, other nodes lose trust in
it and will trade less.  As mentioned before:  possibility of detecting
excessive trades, suggesting content-biased searching (described above)
or offloading (described here).}

\end{itemize}

\subsection{Adversaries within the Mixnet}

These adversaries attack the communication links between nodes. That is,
they attack mix-nets or just cut off nodes from the outside world.  For
more in-depth description of some attacks, see Mixmaster
notes.\footnote{http://www.obscura.com/\~{}loki/remailer/remailer-essay.html} 

\begin{itemize}
\item Timing packets through mixnet nodes:  Anonymity \\
Relate timing of traffic in and out of node, in order to determine
last-hop / next-hop route of packet. \\ 
{\it Initial solution to include delays in resending messages.  Adds
extra latency and still open to traffic analysis attack, especially if
traffic through mixnet node is small.  \\
Reordering of packets witnesses mixnet node keeping N packets.  When
(N+1) packet arrives, send out random packet chosen from (N+1) pool.
Attack:  flood node with many more than N packets, able to determine
which is yours. \\
Current implemention of Mixmaster uses both delay and reordering.
Periodically send out all but N messages.  Possible flood attack still
available, provided DoS attack keeps any other real messages from
entering pool.}

\item Size of mixnet packets:  Anonymity \\
Analyze traffic through node, examining packet size to determine
last-hop / next-hop route of packet. \\
{\it All packets should be same size:  pad messages.}

\item Replay attack:  Anonymity \\
A node receives a message with a certain reply block or persistent id.
Either follow message to destination by resending same message to dest
many times, or attempt to reverse-traceroute the sending by flooding the
mixnet with messages for that sender.  The attacker can then perform
traffic analysis to detect which edges of the mixnet see a rise in
traffic, suggesting the route to the given destination. \\
{\it Mixmaster suggests adding a random id number for each message.
This stops the forward-traceroute, as a mixnet node will not resend a
message that is already sent (by performing a db lookup on the id or,
more advanced, implement some double-spending policy through digital
cash. \\
Unresolved:  how does this stop reverse tracerouting?  An adversary can
simply flood the mixnet with different messages, all for the same
destination.  Link padding and high traffic might help, but traffic
analysis might exposure routing information.}

\item Recover and read mixnet messages: Anonymity \\
{\it The cryptographic security of layered encryption scheme should
prevent an adversary from computationally cracking the onion.}

\item  Lossyness of mixnet:  System Integrity \\
Messages may be lost due to both active adversaries or passive system
failure.  This loss might have several effects on the system:
\begin{itemize}
\item Trading protocol and receipts
\item Broadcasts \\
{\it Termination awareness:  knowledge that all nodes have received an identical message.}
\item Retrieving shares \\
{\it Robust information dispersal and recovery.}
\item Trust system \\
{\it The quantity of trust considerations due to node interactions
should far outweigh possible effects of mixnet lossyness.}
\end{itemize}
\end{itemize}



\subsection{Adversaries between the Servnet nodes and Mixnet}



\subsection{Rogue Users}



\end{document}

