\documentclass[landscape]{slides}

\usepackage{color}
\pagecolor{blue}
\color{yellow}

\newif\ifpdf
\ifx\pdfoutput\undefined
   \pdffalse
\else
   \pdfoutput=1
   \pdftrue
\fi

\begin{document}
\ifpdf
  \pdfcompresslevel=9
  \pdfpagewidth=\the\paperwidth
  \pdfpageheight=\the\paperheight
\fi

\begin{slide}
\begin{center}
Why is anonymity so hard?\\
\vspace{1in}
Roger Dingledine\\
\vspace{.5in}
The Free Haven Project\\
\end{center}
\end{slide}

\begin{slide}
\begin{center}
Talk overview
\end{center}
\begin{itemize}
\item Motivation
\item Anonymity systems
\item In-depth example: Onion Routing
\item Some reasons why anonymity is hard
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Many people need anonymity
\end{center}
\begin{itemize}
\item Political dissidents in oppressive countries
\item Governments want to do operations secretly.
\item Corporations are vulnerable to traffic analysis
(corporate \\espionage) --- VPNs, encryption don't cut it.
\item Individuals are tracked and profiled daily. Imagine what they'll
have in your dossier in twenty years.
\item (If that doesn't scare you, think of your kids.)
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Single-hop proxies
\end{center}
\begin{itemize}
\item Most popular, easiest to deploy
\item Single point of failure (legal, technical)
\item Anonymizer, Safeweb, ...
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Adversary characteristics
\end{center}
\begin{itemize}
\item External (wires) or Internal (participants)
\item Passive or Active
\item Local or Global
\item Static or Adaptive
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
A MIX node
\end{center}
\begin{itemize}
\item Messages change appearance after decryption
\item Each MIX batches and reorders messages
\item Messages are all the same length
\item Store and forward (slow) to maintain anonymity sets
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
A MIX cascade
\end{center}
\begin{itemize}
\item Use multiple nodes to distribute trust: any one node can provide
anonymity.
\item Anonymity comes from the more \emph{users}, not more nodes.
\item Assumes a global adversary
\item Dangers: trickle attacks, easy to watch endpoints
\item Example: Web MIXes, Java Anon Proxy
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Free-route MIX networks
\end{center}
\begin{itemize}
\item User picks a path through the network
\item Goal is to hide message's \emph{path}
\item Needs dummy traffic (inefficient, poorly understood) to \\
protect against global adversaries (lots of traffic may work too?)
\item Example: Mixmaster
\end{itemize}
\end{slide}

%slide 9, crowds (freenet)
\begin{slide}
\begin{center}
Crowds: plausibly deniable web browsing
\end{center}
\begin{itemize}
\item ``Blending into a crowd''
\item Users forward requests within their crowd
\item At each forward, with probability $p$ the request is forwarded
to another member; else it goes to the webserver.
\item So the webserver cannot know which member of the crowd made the
request.
\item No encryption/mixing: totally vulnerable to global adversary
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Zero Knowledge's Freedom Network
\end{center}
\begin{itemize}
\item Connection-oriented (low latency)
\item Paid ISPs to run Freedom nodes
\item Tunnelled all traffic (udp, tcp, icmp --- everything) through the Freedom network
\item But not enough users to make it viable
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Onion Routing
\end{center}
\begin{itemize}
\item Connection-oriented (low latency)
\item Long-term connections between Onion Routers \\
link padding between the routers
\item Aims for security against traffic analysis, not traffic \\confirmation
\item Users should run node, or anonymize connection to first node,
for best privacy
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
(Onion routing intro)
\end{center}
\end{slide}

\begin{slide}
\begin{center}
Some technical problems for Onion Routing:
\end{center}
\end{slide}

\begin{slide}
\begin{center}
Convenient/Usable Proxies
\end{center}
\begin{itemize}
\item Currently we have an \emph{application proxy} for each protocol,
which feeds into the \emph{onion proxy}. Users should run both.
\item But we really ought to intercept all traffic -- otherwise we need
to modify applications so they don't leak info.
\item ...and nobody will use it if we need all these proxies (not true:
p2p systems?)
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Oh yeah, and I wrote the Onion Routing code
\end{center}
\begin{itemize}
\item It's GPLed ... but it's complicated.
\item Send me mail and I'll point you to it.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Ideal threat model
\end{center}
\begin{itemize}
\item Global passive adversary -- can observe \emph{everything}
\item Owns half the nodes
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Link padding and topology
\end{center}
\begin{itemize}
\item Remember that our goal is to hide the \emph{path}
\item Without link padding, adversary can observe when new \\connections
start, and where they go.
\item $n^2$ link padding is insane, but anything less seems unsafe.
\item Open problem: what's the right compromise?
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Timing attacks
\end{center}
\begin{itemize}
\item If the adversary owns two nodes on your path, he can \\recognize that
they're on the same path
\item Works passively (counting and watching packets and timing)
or actively (delaying and batching packets so they're \\optimally
recognizable).
\item An external active adversary can do this by saturating links or
otherwise delaying messages into a certain profile which is recognizable
downstream.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Tagging attacks
\end{center}
\begin{itemize}
\item Onion routing uses a stream cipher to encrypt the data stream
going in each direction.
\item An adversary owning a node -- or a link! -- can flip a byte in
the data stream and look for an anomalous byte at the exit point (say,
when it talks to a webserver).
\item This sort of thing is generally solved by including a hash, but
it's more complex than that.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Long-term intersection attacks
\end{center}
\begin{itemize}
\item The fact that not all users are sending messages all the
time leaks information.
\item By observing these patterns over time, we can learn more and more
confidently who is sending mail, to whom, when, etc.
\item Major unsolved problem in anonymity systems.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
More realistic threat model
\end{center}
\begin{itemize}
\item We must retreat to protecting against \emph{traffic analysis},
not \emph{traffic confirmation}.
\item Reasonable threat model still an open problem too.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Anonymity is hard for economic/social reasons too
\end{center}
\begin{itemize}
\item Anonymity requires \emph{inefficiencies} in computation, bandwidth,
storage
\item Unlike encryption, it's not enough for just one person to want
anonymity --- the infrastructure must participate
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
\emph{Other people} provide your anonymity (noise)
\end{center}
\begin{itemize}
\item The more noise, the more anonymous something in that noise is
\item You're always better off going where the noise is
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
More users is good
\end{center}
\begin{itemize}
\item High traffic $\Rightarrow$ better performance
\item Better performance $\Rightarrow$ high traffic
\item Attracts more users: faster \emph{and} more anonymous
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
But trust bottlenecks can break everything
\end{center}
\begin{itemize}
\item Nodes with more traffic must be more trusted
\item Adversary who wants more traffic should provide good service
\item (and knock down other good providers)
\item Performance and efficiency metrics \emph{cannot} distinguish
bad guys
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Strong anonymity requires distributed trust
\end{center}
\begin{itemize}
\item An anonymity system can't be just for one entity
\item (even a large corporation or government)
\item So you must carry traffic for others to protect yourself
\item But those others don't want to trust their traffic to just one
entity either
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Can we fund it by offering service for money?
\end{center}
\begin{itemize}
\item Freedom taught us that end-users won't pay enough for strong anonymity
\item (Ok, ok, it's more complicated than that.)
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Can we get volunteers to run nodes?
\end{center}
\begin{itemize}
\item Liability, especially for exit nodes
\item Having lots of nodes might work, but making an example of a few
well-chosen nodes can scare everybody
\item We can allow nodes to set individual exit policies
\item Remains an open problem
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Pseudospoofing: volunteers are a danger too
\end{center}
\begin{itemize}
\item Are half your nodes run by a single bad guy?
\item Global PKI to ensure unique identities? No.
\item Decentralized trust flow algorithms? Not yet.
\item Still a major open problem for dynamic decentralized anonymity
systems
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Need to manage incentives well
\end{center}
\begin{itemize}
\item Users have incentive to run a node, to get more anonymity. That's
a good start.
\item Dummy traffic can help maintain anonymity -- but why should others
send dummy traffic to help \emph{your} anonymity?
\item If anonymity for all requires each user doing similar things,
how do we deal with users who don't want as much anonymity?
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Even customization and preferential service are risky (1)
\end{center}
\begin{itemize}
\item It's tempting to let users choose security and robustness \\parameters
\item Eg, how many replicas of my file should I create? \\
or how many pieces should I break my file into?
\item But a file replicated many times stands out.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Even customization and preferential service are risky (2)
\end{center}
\begin{itemize}
\item We'd like to let clients customize to barter better, e.g. in systems
like Mojonation
\item We'd like to let users pay (or pay more) for better service or
preferential treatment
\item But the hordes in the coach seats are better off anonymity-wise
than those in first class.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
An example: Directory servers
\end{center}
\begin{itemize}
\item Distribute location, capabilities, key info, performance stats
\item A single directory server is a point of failure
\item Redundant directory servers: must be (provably!) \\synchronized to avoid
partitioning attacks
\item Can distinguish between clients that use static lists and clients
that update frequently
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Directory servers (2)
\end{center}
\begin{itemize}
\item But even if client information is uniform, nodes can still do trickle
attack: hold message until other clients have different information.
\item Introducing reputation means adversary has new avenue to manipulate
client information
\item Tension between giving clients accurate timely information, and
preventing adversary from manipulating client behavior
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Conclusion: we're screwed
\end{center}
\begin{itemize}
\item Usability is a \emph{security} objective: anonymity systems are\\
nothing without users.
\item It's critical that we integrate privacy into the systems we use
to interact.
\item But it's hard enough to build a killer app. \\
It's going to be really really hard to solve all the factors at once.
\item Our current directions aren't going to work, from an incentive and
usability perspective. We need to rethink.
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
A point of light: Mixminion
\end{center}
\begin{itemize}
\item High-latency free-route mix network
\item Fixes many of the problems with Mixmaster
\item I'll be talking about it on Friday
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Another point of light: synchronous systems
\end{center}
\begin{itemize}
\item Each message has a deadline by which the node must pass it on
\item Length of paths is fixed, paths might even be public
\item Anonymity is now based on size of batch at widest point, even
for free-route systems
\item Improves flooding/trickle attacks
\item But harder to synchronize, especially for low-latency systems
\end{itemize}
\end{slide}

\begin{slide}
\begin{center}
Privacy Enhancing Technologies workshop
\end{center}
\vspace{1in}
\begin{center}
March 26-28, 2003\\
Dresden, Germany\\
http://petworkshop.org/
\end{center}
\end{slide}

\end{document}