[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-cvs] final slides used for the talk this morning
Update of /home/freehaven/cvsroot/doc/blackhat02
In directory moria.seul.org:/home/arma/work/freehaven/doc/blackhat02
Modified Files:
slides-bh02.pdf slides-bh02.tex
Log Message:
final slides used for the talk this morning
Index: slides-bh02.pdf
===================================================================
RCS file: /home/freehaven/cvsroot/doc/blackhat02/slides-bh02.pdf,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
Binary files /tmp/cvsvrTBPz and /tmp/cvsZAEJb2 differ
Index: slides-bh02.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/blackhat02/slides-bh02.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- slides-bh02.tex 8 Jul 2002 06:24:38 -0000 1.1
+++ slides-bh02.tex 31 Jul 2002 20:48:19 -0000 1.2
@@ -1,3 +1,4 @@
+
\documentclass[landscape]{slides}
\newif\ifpdf
@@ -15,7 +16,6 @@
\pdfpageheight=\the\paperheight
\fi
-% slide 1
\begin{slide}
\begin{center}
Why is anonymity so hard?\\
@@ -26,7 +26,6 @@
\end{center}
\end{slide}
-%slide 2
\begin{slide}
\begin{center}
Talk overview
@@ -34,12 +33,11 @@
\begin{itemize}
\item Motivation
\item Anonymity systems
-\item Why anonymity is hard
-\item Example: Onion Routing
+\item In-depth example: Onion Routing
+\item Some reasons why anonymity is hard
\end{itemize}
\end{slide}
-%slide 3
\begin{slide}
\begin{center}
Many people need anonymity
@@ -55,7 +53,6 @@
\end{itemize}
\end{slide}
-%slide 4
\begin{slide}
\begin{center}
Single-hop proxies
@@ -67,7 +64,6 @@
\end{itemize}
\end{slide}
-%slide 5
\begin{slide}
\begin{center}
Adversary characteristics
@@ -80,7 +76,6 @@
\end{itemize}
\end{slide}
-%slide 6
\begin{slide}
\begin{center}
A MIX node
@@ -93,7 +88,6 @@
\end{itemize}
\end{slide}
-%slide 7
\begin{slide}
\begin{center}
A MIX cascade
@@ -101,15 +95,13 @@
\begin{itemize}
\item Use multiple nodes to distribute trust: any one node can provide
anonymity.
-\item Anonymity comes from the number of users, \emph{not} number
-of nodes.
+\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}
-%slide 8
\begin{slide}
\begin{center}
Free-route MIX networks
@@ -118,7 +110,7 @@
\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
+protect against global adversaries (lots of traffic may work too?)
\item Example: Mixmaster
\end{itemize}
\end{slide}
@@ -126,7 +118,7 @@
%slide 9, crowds (freenet)
\begin{slide}
\begin{center}
-Crowds: anonymous web browsing
+Crowds: plausibly deniable web browsing
\end{center}
\begin{itemize}
\item ``Blending into a crowd''
@@ -139,7 +131,18 @@
\end{itemize}
\end{slide}
-%slide 10
+\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
@@ -154,22 +157,123 @@
\end{itemize}
\end{slide}
-%slide 11
\begin{slide}
\begin{center}
-Zero Knowledge's Freedom Network
+(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 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
+\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}
-But anonymity is hard
+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,
@@ -231,7 +335,7 @@
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 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}
@@ -264,10 +368,24 @@
\begin{slide}
\begin{center}
-Even customization and preferential service are risky
+Need to manage incentives well
\end{center}
\begin{itemize}
-\item It's tempting to let users choose security parameters
+\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.
@@ -276,7 +394,7 @@
\begin{slide}
\begin{center}
-Even customization and preferential service are risky
+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
@@ -295,7 +413,7 @@
\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 well-synchronized to avoid
+\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
@@ -304,7 +422,7 @@
\begin{slide}
\begin{center}
-Directory servers (cont)
+Directory servers (2)
\end{center}
\begin{itemize}
\item But even if client information is uniform, nodes can still do trickle
@@ -327,8 +445,46 @@
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. We need to rethink.
+\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}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/