[tor-commits] [tech-reports/master] Convert Nick's and Mike's whitepaper to LaTeX.
karsten at torproject.org
karsten at torproject.org
Mon Sep 23 07:54:48 UTC 2019
commit 5e5007b4d9f7d974c5780fc9f94b5ca1e2c75737
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date: Mon Sep 16 10:41:12 2019 +0200
Convert Nick's and Mike's whitepaper to LaTeX.
---
...annel-analysis.md => side-channel-analysis.tex} | 122 +++++++++++----------
1 file changed, 64 insertions(+), 58 deletions(-)
diff --git a/2018/side-channel-analysis/side-channel-analysis.md b/2018/side-channel-analysis/side-channel-analysis.tex
similarity index 86%
rename from 2018/side-channel-analysis/side-channel-analysis.md
rename to 2018/side-channel-analysis/side-channel-analysis.tex
index f9454de..4824c3a 100644
--- a/2018/side-channel-analysis/side-channel-analysis.md
+++ b/2018/side-channel-analysis/side-channel-analysis.tex
@@ -1,17 +1,21 @@
-# Towards Side Channel Analysis of Datagram Tor vs Current Tor
+\documentclass{tortechrep}
+\begin{document}
- Version 0.6, 27 Nov 2018
+\author{Nick Mathewson and Mike Perry}
+\contact{\{nickm,mikeperry\}@torproject.org}
+\reportid{2018-11-001}
+\date{November 27, 2018}
+\title{Towards Side Channel Analysis of Datagram Tor vs Current Tor}
+\maketitle
- by Nick Mathewson and Mike Perry
-
-## Disclaimers
+\section{Disclaimers}
This whitepaper assumes that you know how Tor works.
There are probably some very good references here that we didn't
remember to cite.
-## Introduction
+\section{Introduction}
Tor's current design requires that its data cells be transmitted
from one end of a circuit to the other using a reliable, in-order
@@ -46,31 +50,33 @@ our description of the problem space will inspire, not discourage,
future experiments in this area, and help with a holistic understanding
of the risks, rewards, and future areas of work.
-### A toy system
+\subsection{A toy system}
We will be analyzing a system that differs from Tor in the following
ways.
- * The link between a client and its guard, and between each pair
+\begin{itemize}
+\item The link between a client and its guard, and between each pair
of relays uses DTLS over UDP: packets can be dropped or
re-ordered by an attacker on the link, but not modified, read,
or forged. Each DTLS packet contains an integer number of cells.
- * Each circuit between a client and an exit traverse several
+\item Each circuit between a client and an exit traverse several
relays, as before. The cells on a circuit are no longer
guaranteed to arrive reliably, but can be dropped or re-ordered
on the wire, or by a relay.
- * To provide reliable service end-to-end, the client and the
+\item To provide reliable service end-to-end, the client and the
exit each use a TCP-like protocol to track which application
bytes have been sent and received. Received data is
acknowledged; dropped data is retransmitted.
- * The cryptography to be used for circuit encryption is not
+\item The cryptography to be used for circuit encryption is not
specified here.
- * A reliable signaling mechanism between relays (to create,
+\item A reliable signaling mechanism between relays (to create,
destroy, and maintain circuits) is not specified here.
+\end{itemize}
(It is likely that many readers will be able to design a system that
resists the attacks below better than the design above. But please
@@ -80,7 +86,7 @@ clearly superior to Tor as it is today. Before we can deploy, we
will need not just defenses, but also a systemic way to compare the
effect of these defenses, used together, to the Tor status quo.)
-## Some preexisting attacks to consider
+\section{Some preexisting attacks to consider}
To put the datagram-based attacks into context, we'll start out by
listing some attacks against the current non-datagram Tor design
@@ -100,7 +106,7 @@ alter packet timing information in transit.
In many cases, we don't have good metrics or evaluation methodology
to determine how much harder or easier one attack is than another.
-### End-to-end passive traffic correlation attacks.
+\subsection{End-to-end passive traffic correlation attacks.}
Here's the gold-standard base-line attack: an attacker who can watch
any two points on the same circuit is assumed to be able to realize,
@@ -129,7 +135,7 @@ padding, it is not yet clear if we can use these defenses in an
affordable way against a correlation attack, and it is hard to
measure their effectiveness on a realistic Tor-sized network.
-### Data tagging side-channels by relays
+\subsection{Data tagging side-channels by relays}
If two relays are on the same circuit, they can surreptitiously
communicate with one another transforming the data in the RELAY
@@ -148,7 +154,7 @@ To defend against this, we plan to replace our encryption with a
non-malleable algorithm. See for example proposals 202, 261, and
295.
-### Destructive side-channels (internal)
+\subsection{Destructive side-channels (internal)}
Even if we remove the malleability in Tor's encryption, a smaller
side-channel remains: A dishonest relay can destroy a circuit at any
@@ -181,7 +187,7 @@ information that can be sent in this way rather than eliminate it.
We also lack methodology to measure the rate of information in this
case, to help determine if we can successfully reduce it further.
-### Destructive network probes (external)
+\subsection{Destructive network probes (external)}
Though TLS is resilient against many forms of active attacks, it
can't resist an attacker who focuses against the underlying TCP
@@ -195,7 +201,7 @@ than it would be against (some) datagram-based designs, since
datagram-based designs are resilient to more kinds of traffic
interference.
-### Timing-based watermarking attacks
+\subsection{Timing-based watermarking attacks}
Hostile relays can also introduce a side channels to a circuit by
introducing patterned delays into the cells. For example, a relay
@@ -206,21 +212,18 @@ in that time period.
An attacker can also mount this attack without controlling relays:
if the attacker performs a DoS attack against a relay or its
traffic, it can observe changes in the traffic volume elsewhere on
-the network.
-
-[See https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf and
-http://cybercentre.cs.ttu.ee/wp/wp-content/uploads/2017/01/crw2017_final.pdf ]
+the network.%
+\footnote{See \url{https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf} and
+\url{http://cybercentre.cs.ttu.ee/wp/wp-content/uploads/2017/01/crw2017_final.pdf}.}
The bandwidth of this side-channel will be limited, since other
relays on the network will naturally buffer and delay traffic,
obscuring the pattern some. There are also limits to how long
-packets can be delayed before the relay is no longer usable.
-
-[See:
- - Rainbow: https://www.freehaven.net/anonbib/cache/ndss09-rainbow.pdf
- - Swirl: https://www.freehaven.net/anonbib/cache/ndss11-swirl.pdf
- - Backlit (detection):
- https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf ]
+packets can be delayed before the relay is no longer usable.%
+\footnote{See:
+Rainbow (\url{https://www.freehaven.net/anonbib/cache/ndss09-rainbow.pdf});
+Swirl: (\url{https://www.freehaven.net/anonbib/cache/ndss11-swirl.pdf});
+Backlit (detection): (\url{https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf})}
Proposals for resisting this type of watermarking attack are mostly
of the same type that would be needed for resisting end-to-end
@@ -231,16 +234,15 @@ patterns. We lack a unified framework to tell us how much stronger
this adversary is than the passive one, especially against various
defenses.
-### Traffic injection attacks
+\subsection{Traffic injection attacks}
Related to the active timing attack, in some positions (like exit
and RP) relays can inject cells that are ignored by the other
endpoint. These injected patterns will not impact the user's
experience, but will allow unique traffic patterns to be sent and
-detected by the adversary at crucial times.
-
-[See
-https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf]
+detected by the adversary at crucial times.%
+\footnote{See
+\url{https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf}}
These injection attacks arise from former adherence to Postel's
Maxim. Tor has since departed from this maxim, and instead opted for
@@ -248,12 +250,12 @@ stricter forward compatibility through feature versioning, but
removing instances in the codebase where injected cells can be
permitted has proven challenging.
-## Attacks unique to datagram designs
+\section{Attacks unique to datagram designs}
Here are some attacks that are enabled by (or at any rate behave
differently under) datagram-based designs.
-### Traffic-stream tagging (by relays and internet links)
+\subsection{Traffic-stream tagging (by relays and internet links)}
Because the new system permits a number of transformations on
traffic that were not previously allowed, we need to look at how
@@ -291,7 +293,7 @@ the noise of this attack; we lack metrics to tell us how much, and
we have no framework as of yet to measure the throughput of the
resulting side channel in these conditions.
-### Traffic Fingerprinting of TCP-like systems
+\subsection{Traffic Fingerprinting of TCP-like systems}
Today, because Tor terminates TCP at the guard node, there is
limited ability for the exit node to fingerprint client TCP
@@ -324,7 +326,7 @@ OS-specific features or try to learn things about their environment
over time, across different connections.
-### Retransmit-based watermarking
+\subsection{Retransmit-based watermarking}
Even if all TCP-like implementations are identical, they will
retransmit with different timing and volume based on which cells
@@ -340,7 +342,7 @@ difference in degree would come from how much easier it is to
perform this attack than the delay based watermarking attacks on
traditional Tor above.
-### Congestion and flow control interference
+\subsection{Congestion and flow control interference}
To the extent that the TCP-like stack uses information learned from
one stream to alter its behavior on another stream, an attacker can
@@ -352,8 +354,8 @@ extent that their bandwidth is limited. But some may have more than
necessary.
-### Non-malleable encryption designs only currently exist for in-order
-transports (or the return of data tagging attacks)
+\subsection{Non-malleable encryption designs only currently exist for in-order
+transports (or the return of data tagging attacks)}
Our proposed defenses against data tagging require us to move to
non-malleable encryption, with each cell's encryption tweaked by a
@@ -382,7 +384,7 @@ a way to send a rolling MAC out of band, to ensure integrity of
packets between those cells. But can we do better? Can middle nodes
enforce integrity in some other way?
-### The risks of success: lower latency strengthens timing attacks?
+\subsection{The risks of success: lower latency strengthens timing attacks?}
There are two factors that make timing-correlation and
timing-watermark attacks more difficult in practice: similarity
@@ -392,8 +394,8 @@ extent we successfully reduce this distortion by lowering latency,
it seems that we'll make these attacks more powerful.
In particular, geolocation attacks based on observed circuit setup
-times may get worse [See again
-https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf].
+times may get worse.\footnote{See again
+\url{https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf}}
We're already making improvements to Tor that may make these attacks
worse -- Tor latency has dropped and will continue to drop due to
@@ -417,7 +419,7 @@ it is also not clear to what degree adding delay is more useful than
adding more padding.
-## Towards comparing attacks
+\section{Towards comparing attacks}
A high-bandwidth attack is worse than a low-bandwidth attack. One
bit is enough to send "is this the targeted user?", but 32 bits is
@@ -447,7 +449,7 @@ literature is often not reliable, due to differing implementations,
in addition to differing methodology and evaluation frameworks.
-## Open Questions
+\section{Open Questions}
Why permit reordering? There are schemes (like order-preserving
encryption) that we could deploy on middle nodes to prevent
@@ -461,11 +463,11 @@ lack the domain expertise to know what this tradeoff is.
Related: what cryptography to use? Our current stateful encryption
schemes benefit from having access to "all previous cells" when
encrypting or decrypting each following cell. If we allow a cell to
-be {de,en}crypted before previous cells are received, we'll need a
+be \{de,en\}crypted before previous cells are received, we'll need a
new model for onion-routing cryptography -- possibly one with
significantly bigger headers.
-## Future work
+\section{Future work}
We hope to investigate these issues with researchers and others in the
Tor community as we work towards solutions to help scale and strengthen
@@ -477,29 +479,33 @@ about improved network designs can bring answers and broader
improvements. We look forward to working with others interested in
helping solve these problems to design a better Tor.
-## Acknowledgments
+\section{Acknowledgments}
Our thanks to Chelsea Komlo for many helpful suggestions and
comments on earlier drafts of this whitepaper, and for writing the
request for future work.
-## Further reading
+\section{Further reading}
-Steven Murdoch, "Comparison of Tor Datagram Designs", 2011.
-https://murdoch.is/papers/tor11datagramcomparison.pdf
+\begin{itemize}
+\item Steven Murdoch, "Comparison of Tor Datagram Designs", 2011.
+\url{https://murdoch.is/papers/tor11datagramcomparison.pdf}
-Mashael AlSabah and Ian Goldberg. "PCTCP: per-circuit
+\item Mashael AlSabah and Ian Goldberg. "PCTCP: per-circuit
TCP-over-IPsec transport for anonymous communication overlay
networks", 2013.
-http://cacr.uwaterloo.ca/techreports/2013/cacr2013-09.pdf
+\url{http://cacr.uwaterloo.ca/techreports/2013/cacr2013-09.pdf}
-Michael F. Nowlan, David Wolinsky, and Bryan Ford.
+\item Michael F. Nowlan, David Wolinsky, and Bryan Ford.
"Reducing Latency in Tor Circuits with Unordered Delivery",
2013.
-https://www.usenix.org/system/files/conference/foci13/foci13-nowlan.pdf
+\url{https://www.usenix.org/system/files/conference/foci13/foci13-nowlan.pdf}
-Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann
+\item Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann
The Sniper attack: Anonymously Deanonymizing and Disabling the Tor
Network", 2013
-https://www.nrl.navy.mil/itd/chacs/sites/edit-www.nrl.navy.mil.itd.chacs/files/pdfs/13-1231-3743.pdf
+\url{https://www.nrl.navy.mil/itd/chacs/sites/edit-www.nrl.navy.mil.itd.chacs/files/pdfs/13-1231-3743.pdf}
+\end{itemize}
+
+\end{document}
More information about the tor-commits
mailing list