[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tech-reports/master] Convert Nick's and Mike's whitepaper to LaTeX.



commit 5e5007b4d9f7d974c5780fc9f94b5ca1e2c75737
Author: Karsten Loesing <karsten.loesing@xxxxxxx>
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}
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits