commit 5e5007b4d9f7d974c5780fc9f94b5ca1e2c75737 Author: Karsten Loesing karsten.loesing@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%7D 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%7D); +Swirl: (\url{https://www.freehaven.net/anonbib/cache/ndss11-swirl.pdf%7D); +Backlit (detection): (\url{https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf%7D)%7D
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%7D%7D
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%7D%7D
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%7D
-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%7D
-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%7D
-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/fil... +\url{https://www.nrl.navy.mil/itd/chacs/sites/edit-www.nrl.navy.mil.itd.chacs/fil... +\end{itemize} + +\end{document}