zecfoundation
/
tech-reports
mirror of https://github.com/ZcashFoundation/tech-reports.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Zcash Network Privacy Assessment (#1) 

Add network privacy assessment and discussion of future mitigations.
This commit is contained in:
Chelsea Komlo 2020-08-31 22:28:08 -04:00 committed by GitHub
parent 18b7b56fa8
commit bf122426a0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 1008 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
network-privacy-assessment/.gitignore vendored Normal file
View File

@ -0,0 +1,14 @@
*.bbl
*.bbg
*.blg
*.aux
*.log
*.out
*.nav
*.snm
*.toc
*~
*.swp
*.pyc
*.pyo
__pycache__

16
network-privacy-assessment/Makefile Normal file
View File

@ -0,0 +1,16 @@
LATEX = pdflatex
BIBTEX = bibtex
MAIN = network-privacy
all: $(MAIN).pdf
$(MAIN).pdf: $(MAIN).tex $(MAIN).bbl
while $(LATEX) $(MAIN) && grep -q "Rerun to get" $(MAIN).log ; do true; done
$(MAIN).bbl: $(MAIN).bib
$(LATEX) $(MAIN)
$(BIBTEX) $(MAIN)
clean:
rm -f *.bbl *.blg network-privacy.pdf *.aux *.log *.out

5
network-privacy-assessment/README.md Normal file
View File

@ -0,0 +1,5 @@
# Technical Report for Zcash Threat Model and Network Privacy Assessment
This is a work-in-progress project to formalize the threat model for Zcash and
perform an assessment as to the privacy improvements that can be offered by
different network privacy mechanisms.

169
network-privacy-assessment/network-privacy.bib Normal file
View File

@ -0,0 +1,169 @@
@misc{zcash-spec,
author = {Daira Hopwood and Sean Bowe and Taylor Hornby and Nathan Wilcox},
title = {{Zcash Protocol Specification}},
howpublished = {\url{https://github.com/zcash/zips/blob/master/protocol/protocol.pdf}},
note = {
{last accessed 2020-05-29}
},
year = {2020}
}
@misc{light-wallet-spec,
author = {George Tankersley, Jack Grigg},
title = {{Light Client Protocol for Payment Detection}},
howpublished = {\url{https://github.com/gtank/zips/blob/light_payment_detection/zip-XXX-light-payment-detection.rst}},
note = {
{last accessed 2020-05-29}
},
year = {2018}
}
@misc{katzenpost,
author = {Yawning Angel and George Danezis and Claudia Diaz and Ania Piotrowska and David Stainton},
title = {{Katzenpost Mix Network Specification}},
howpublished = {\url{https://katzenpost.mixnetworks.org/docs/specs/mixnet.html}},
note = {
{last accessed 2019-12-16}
},
year = {2017}
}
@inproceedings{Dingledine2004TorTS,
title={{Tor: The Second-Generation Onion Router}},
author={Roger Dingledine and Nick Mathewson and Paul F. Syverson},
booktitle={USENIX Security Symposium},
year={2004}
}
@inproceedings{Piotrowska:2017:LAS,
author = {Piotrowska, Ania M. and Hayes, Jamie and Elahi, Tariq and Meiser, Sebastian and Danezis, George},
title = {{The Loopix Anonymity System}},
booktitle = {Proceedings of the 26th USENIX Conference on Security Symposium},
series = {SEC'17},
year = {2017},
pages = {1199--1216},
numpages = {18},
url = {http://dl.acm.org/citation.cfm?id=3241189.3241283},
acmid = {3241283},
publisher = {USENIX Association},
}
@misc{fanti2018dandelion,
title={Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees},
author={Giulia Fanti and Shaileshh Bojja Venkatakrishnan and Surya Bakshi and Bradley Denby and Shruti Bhargava and Andrew Miller and Pramod Viswanath},
year={2018},
eprint={1805.11060},
archivePrefix={arXiv},
primaryClass={cs.CR}
}
@InProceedings{anon-bitcoin,
author="Koshy, Philip
and Koshy, Diana
and McDaniel, Patrick",
editor="Christin, Nicolas
and Safavi-Naini, Reihaneh",
title="An Analysis of Anonymity in Bitcoin Using P2P Network Traffic",
booktitle="Financial Cryptography and Data Security",
year="2014",
publisher="Springer Berlin Heidelberg",
address="Berlin, Heidelberg",
pages="469--485",
isbn="978-3-662-45472-5"
}
@misc{dandelion,
title={Dandelion: Redesigning the Bitcoin Network for Anonymity},
author={Shaileshh Bojja Venkatakrishnan and Giulia Fanti and Pramod Viswanath},
year={2017},
eprint={1701.04439},
archivePrefix={arXiv},
primaryClass={cs.CR}
}
@article{BojjaVenkatakrishnan:2017:DRB,
author = {Bojja Venkatakrishnan, Shaileshh and Fanti, Giulia and Viswanath, Pramod},
title = {{Dandelion: Redesigning the Bitcoin Network for Anonymity}},
journal = {Proc. ACM Meas. Anal. Comput. Syst.},
issue_date = {June 2017},
volume = {1},
number = {1},
month = jun,
year = {2017},
issn = {2476-1249},
pages = {22:1--22:34},
articleno = {22},
numpages = {34},
url = {http://doi.acm.org/10.1145/3084459},
doi = {10.1145/3084459},
acmid = {3084459},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {bitcoin, cryptocurrencies},
}
@article{Fanti:2018:DLC,
author = {Fanti, Giulia and Venkatakrishnan, Shaileshh Bojja and Bakshi, Surya and Denby, Bradley and Bhargava, Shruti and Miller, Andrew and Viswanath, Pramod},
title = {{Dandelion++: Lightweight Cryptocurrency Networking with Formal
Anonymity Guarantees}},
journal = {Proc. ACM Meas. Anal. Comput. Syst.},
issue_date = {June 2018},
volume = {2},
number = {2},
month = jun,
year = {2018},
issn = {2476-1249},
pages = {29:1--29:35},
url = {http://doi.acm.org/10.1145/3224424},
doi = {10.1145/3224424},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {anonymity, cryptocurrencies, p2p networks},
}
@misc{tor-specification,
author = {Roger Dingledine and Nick Mathewson},
title = {{Tor Protocol Specification}},
howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt}},
note = {
{last accessed 2020-06-22}
},
year = {2020}
}
@article{pir,
author = {Chor, Benny and Kushilevitz, Eyal and Goldreich, Oded and Sudan, Madhu},
title = {Private Information Retrieval},
year = {1998},
issue_date = {Nov. 1998},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {45},
number = {6},
issn = {0004-5411},
url = {https://doi.org/10.1145/293347.293350},
doi = {10.1145/293347.293350},
journal = {J. ACM},
month = nov,
pages = {965–981},
numpages = {17}
}
@article{JAWAHERI2020101684,
title = "Deanonymizing Tor hidden service users through Bitcoin transactions analysis",
journal = "Computers \& Security",
volume = "89",
pages = "101684",
year = "2020",
issn = "0167-4048",
doi = "https://doi.org/10.1016/j.cose.2019.101684",
url = "http://www.sciencedirect.com/science/article/pii/S0167404818309908",
author = "Husam Al Jawaheri and Mashael Al Sabah and Yazan Boshmaf and Aiman Erbad",
keywords = "Bitcoin, Tor hidden services, Privacy, Deanonymization, Attack",
}

BIN
network-privacy-assessment/network-privacy.pdf Normal file
View File

Binary file not shown.

804
network-privacy-assessment/network-privacy.tex Normal file
View File

@ -0,0 +1,804 @@
\documentclass{article}
\usepackage{amsthm, amsfonts, amssymb, amsmath, graphicx, cancel, framed}
\usepackage{mathtools}
\usepackage{multicol}
\usepackage{multirow}
\usepackage{amsmath}
\usepackage{amsfonts, txfonts}
\usepackage{ifsym}
\usepackage{commath}
\usepackage{amsthm}
\usepackage{caption}
\captionsetup[figure]{font=small,belowskip=-10pt}
\captionsetup[figure]{font=small,aboveskip=3pt}
\usepackage{wasysym}
\usepackage[hyphens]{url}
\urlstyle{same}
\usepackage{xifthen}
\usepackage[usenames,svgnames,table]{xcolor}
\setlength{\marginparsep}{8pt}
\setlength{\marginparwidth}{40pt}
\setlength{\marginparpush}{5pt}
\newcounter{mn}
\setcounter{mn}{1}
\newcommand{\superscript}[1]{\ensuremath{{}^{\textrm{\scriptsize #1}}}}
\newcommand{\roughtext}[1]{\begin{color}{SkyBlue}#1\end{color}}
\newcommand{\mntext}[1]{\colorbox{SkyBlue}{\begin{color}{black}#1\end{color}}}
\newcommand{\mn}[2][]{{\tiny\superscript{\mntext{\arabic{mn}}}}\marginpar{\scriptsize{
\ifthenelse{\isempty{#1}}
{\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}~\raggedright{#2}}}}
{\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}#1 says:~\raggedright{#2}}}}
}}\stepcounter{mn}}
\newcommand\supth{\ensuremath{^{\textrm{\scriptsize th}}}}
\title{Zcash Network Privacy Assessment}
\author{The Zcash Foundation}
\begin{document}
\maketitle
\section{Introduction}
The amount of data leaked about individuals online is ever growing; and
financial data in particular
provides a highly granular lens about personal daily habits.
Zcash is a cryptocurrency that ensures strong financial
privacy for users by leveraging zero-knowledge proofs and randomization
techniques~\cite{zcash-spec} to
protect against data leakage that could otherwise lead to deanonymization of a
payer or
recipient of Zcash. Use of zero-knowledge proofs in this manner ensures that
the raw bytes of a Zcash \emph{shielded} transaction cannot leak identifiable
information about the payer, payee, or amount.
However, an adversary observing the Zcash network
could perform passive or active attacks with the goal of linking
users and their end recipients, even if that adversary cannot decrypt the Zcash
shielded transaction directly. Consequently, ensuring additional mechanisms to
protect against network-level adversaries seeking to deanonymize users is
important.
In this technical report, we assess the capabilities of such nework
adversaries, and present a more formal assessment of network privacy Zcash
users, with a focus on \textit{shielded
transactions}. We identify what is considered sensitive information in the Zcash
ecosystem, potential adversaries, and enumerate several attack vectors.
We then consider several
network privacy mechanisms and assess the extent to which these
mechanisms improve the privacy and security of Zcash users. Finally, we
identify near-term and long-term recommendations for improvements.
\textit{Organization}.
We begin in Section~\ref{background} by discussing background information
useful to understanding the network privacy that Zcash ensures for users. In
Section~\ref{observations}, we describe the difference between adversarial
network models in blockchains as opposed to other applications such as web
browsing or email. In
Section~\ref{threat-model}, we introduce a basic threat model for Zcash.
In Section~\ref{network-privacy-review} we describe the network
privacy mechanisms that we include in our assessment, and in
Section~\ref{network-privacy-assessment} we perform this assessment.
In Section~\ref{future-improvements} we outline furture improvements we are
planning to implement, and we conclude in Section~\ref{conclusion}.
\section{Background} \label{background}
\subsection{Zcash Shielded Transactions}
\label{shielded}
While Zcash does allow for use of unshieleded transactions, in this technical
report we focus on assessing the network privacy for users assuming the use of shielded
transactions. However, we will now briefly describe
the difference between the two transaction types.
As mentioned before, unshielded transactions are similar
to Bitcoin transactions, and expose the pseudonyms of the payer, payee, and the
amount paid. When this information is exposed to the network and persisted
indefinitely to the Blockchain, it is effectively ``Twitter for your bank
account''.
Shielded transactions, on the other hand, expose what is essentially a “one
time pad” to a network observer. Because not only the transaction information
is encrypted, the encryption process itself is randomized such that two
transactions that have identical payers, payees, and transaction amounts result
in bytes that are completely indistinguishable from randomly-generated bytes.
In other words, given only a series of shielded transactions, an adversary
would not be able to gain enough information to distinguish any
\emph{personally identifiable} information about the transaction plaintext.
In other words, while nodes \emph{can} observe information about transactions
such as timing or other fingerprintable network-level anomalies, we are
concerned with the capability of an attacker to use information to tie a
\emph{particular} transaction to \emph{both} its sender and receiver's
real-world identities.
\subsection{Comparison of Zcash Privacy Expectations to Bitcoin}
While Zcash provides the ability to make shielded transactions to completely
hide the information contained within a transaction, users of Zcash can also
make non-shielded transactions. Because Zcash is a fork of Bitcoin,
non-shielded transactions consequently have effectively the same expectation of
privacy as plain Bitcoin transactions, which had been proven to be insecure
against deanonymization attacks~\cite{anon-bitcoin}. In this post, we will
focus on evaluating the setting when shielded transactions.
While both Zcash and Bitcoin have future goals of
stable Tor integration and other network-privacy mechanisms, this routing via
an anonymity layer does not prevent attacks that examine the bytes of the
transaction itself. So unshielded transactions in Zcash and all Bitcoin
transactions leak information to a network observer, which can be exploited to
perform deanonymization attacks. Further, use of network privacy tools may not
completely mitigate deanonymization attacks against unshielded
transactions~\cite{JAWAHERI2020101684}.
\subsection{Zcash Protocol for Producing and Receiving Transactions}
\textbf{Producing a Transaction (Spending Funds)}.
A user wishing to spend
funds can publish a new transaction to the network in several ways. The user
could operate a \emph{full node}, meaning this node also participates in all
network behaviour, such as gossiping transactions, responding to queries for
the current state of the network, etc.
The user can also spend funds via a \emph{light
client} by publishing their transaction to a
\emph{light wallet node}, which itself is a full node which additionally can handle
light wallet functionality. Note that while publishing a transaction to a light
wallet, the user exposes the fact that they are making a Zcash transaction (as
the light wallet learns a particular transaction, along with the IP address of
the user). However, the light wallet will not learn the identity of the
receiver of the funds~\cite{light-wallet-spec}.
\textbf{Receiving a Transaction (Accepting Funds)}. A user receiving a
transaction similarly has two options for how to receive these funds, either
via a full node or via a light wallet node.
An important point to emphasize that because Zcash is a broadcast protocol (all
full nodes sync the full state of the network), a user receiving transactions
via a full node will not expose which transaction they are interested in
receiving. In other words, because full nodes maintain the complete blockchain,
they will not leak to any external party which blocks they require in order to
process receiving of funds.
Similarly, a user fetching transactions from a light wallet will also fetch all
block headers and therefore not expose which transaction they are interested
in. However, one slight exception exists for clients that wish
to learn the full details of a transaction (such as the memo field). For this
case,
they must query the light wallet for those details separately. As such, the
light wallet can link a recipient to a particular transaction in the case the
user queries for extended transaction fields for a specific block~\cite{light-wallet-spec}.
\section{Observations on End-to-End Network Attacks against Blockchains}
\label{observations}
We now describe several observations that we made while assessing the
end-to-end network
privacy of blockchains, where network state
is published and synced to a globally consistent data store such as a blockchain. We contrast
these observations with threats that are typical for a applications where users
are browsing the web, exchanging email, or engaging in a messaging platform,
for example.
As stated previously, we assume the use of \emph{shielded} transactions for the
below analysis.
\textbf{Observation One: PoW Consensus adds more significantly more
end-to-end latency than web application traffic.}
While different cryptocurrency networks have a range of consensus mechanisms,
in Zcash and other proof-of-work (POW) networks today, the latency
between when a transaction is published and when that transaction is included
into the Zcash blockchain is upwards of one minute~\cite{zcash-faq}.
Hence, network privacy mechanisms that are tuned for lower-latency applications
such as web applications will not meaningfully protect against end-to-end
timing attacks in blockchains that use a PoW-based consensus. While such
network privacy mechanisms may frustrate an attacker seeking to deanonymize
only one end of the transaction (such as a mixnet preventing a node from
identifying the source node that published the transaction), this use case in
the setting for Zcash does not allow for end-to-end correlation.
Hence, unless network privacy mechanisms that are indended to frustrate
end-to-end timing attacks
(such as mixnets) impose more latency than the blockchain consensus
protocol itself, such mechanisms do not add additional
meaningful protection against \emph{end-to-end} timing correlation attack.
Such an observation extends to any network privacy mechanism that adds noise,
such as generating dummy packets or transactions, as it is unclear how noise
can be generated and distributed in a truly end-to-end setting.
\textbf{Observation Two: Performing end-to-end correlation attacks in
blockchains require attacking a broadcast network, not a point-to-point link.}
In a setting such as accessing content online or sending messages or emails,
application traffic is sent from a sender to receiver, proxied through a series
of servers. In this setting, an adversary could perform end-to-end correlation
attacks in a number of ways, such as observing distinguishing identifiable
patterns as information enters and leaves the network. The latency of these
applications is important, as faster transmission can increase the possibility for
timing correlation attacks, but so are other factors such as the pattern of
packets or exposed metadata.
However, blockchains create a different landscape for an attacker that
wishes to perform \emph{end-to-end} correlation attacks. Namely, blockchains require
that transactions are \emph{first} included in the blockchain (the global state
of the network), only \emph{after} which the receiver of the funds can learn
about the transaction.
\textbf{Takeaways}
While adversaries can certainly perform \emph{end-to-end} attacks in a blockchain
setting, the above observations indicate that doing so requires different
adversarial models than in other application settings such as for web traffic or email
applications. Hence, we do not consider end-to-end timing or packet correlation
attacks when evaluating general-purpose network privacy tools such as Tor or
general-purpose mixnets in this assessment of network privacy for Zcash in the setting where
shielded transactions are used.
\section{Analysis of Attack Vectors in Zcash}
\label{threat-model}
We now assess attack vectors relevant to Zcash. We define the information of
interest to an attacker as the below tuple.
\textbf{Information of interest: learning the tuple (sender network identity, transaction, receiver network identity).}
This three-tuple of sender network identity, transaction, and receiver network
identity allows for an adversary to link the fact that a
specific sender of Zcash made a payment to a specific receiver, even though the
amount of the payment is not disclosed.
By ``network identity'', we mean the IP address of a sender or receiver, or other
distinguishing information that is not included in the transaction itself. This
differs from the ``on-chain'' identity of a sender or receiver, which Zcash
shielded transactions hide by randomizing addresses.
While the sender and receiver public keys (on-chain identity)
are not exposed by the Zcash transaction itself, an adversary
could learn their network identity by observing or participating in the
network.
\subsection{Adversarial Model}
We begin with a brief review of possible adversaries, whom we will consider in
our analysis of attack vectors.
\textbf{Regular Zcash user:} Allowed to send and receive transactions and act
outside the protocol, just as a real user.
\textbf{Regular Zcash Node Operator:} Can operate one (or many) full Zcash
nodes, and can store and forward all traffic that is sent through the node. Can
query for network information, and store and examine all information it
receives.
\textbf{DNS seeder operators:} Operates the node that is used by new nodes when
bootstrapping to the Zcash network, in order to learn about other nodes in the
network to begin communicating with them directly.
\textbf{Internet Service Providers (ISPs):} Can view traffic sent and received
from either users or Zcash nodes. Can store observed traffic, forward traffic
to other parties, and compare traffic with other traffic.
\textbf{Government actors:} Can issue secret subpoenas and force ISPs and
regular Zcash users to take actions they may not wish to take, such as turning
over secret keys or server logs.
\subsection{Attack Vectors Against Shielded Transaction Use}
As described in Section~\ref{shielded} an adversary could gain more information
about a shielded transaction by observing information exposed to the network.
Keeping this in mind, and assuming that a transaction is shielded, we now
review sensitive information that could be exposed and used for malicious
purposes by a adversary.
We divide attack vectors an adversary can employ using these information leaks
into \emph{in scope} to our immediate network privacy assessment, and \emph{out
of scope}.
\subsubsection{In Scope}
\label{in-scope}
Note that an adversary has the ability to observe both \emph{on-chain} visible
data as well as information or behaviour that is exposed to the network during
the process of submitting a new transaction or receiving a transaction.
\textbf{On-Path end to end correlation attacks:} This attack could occur by an
adversary that can obtain the (sender identity, transaction, receiver identity)
tuple discussed in Section~\ref{threat-model}. By \emph{on-path end to end
correlation}, we include attacks performed by nodes that are directly on the
path between a sender and receiver when publishing or receiving a transaction.
In the current model of Zcash, such an attacks are practical
only when the recipient uses a light wallet in such a manner that leaks the
transaction that the sender or receiver is publishing, as further described in
Section~\cite{light-wallet-spec}.
\textbf{Block access patterns:} Even if a user accessed
information about the Zcash blockchain using an anonymity tool such as Tor, the
access patterns for specific blocks could leak information to network
adversaries, such as the time of day that users requested information about
that block, or its popularity.
\textbf{Denial of Service attacks:} such attacks could be performed against
Zcash nodes, such as DNS seeders refusing to respond to certain queries, or
against Zcash users, such as light wallets refusing to service certain classes
of IP addresses.
\subsubsection{Deferred Threats for Future Improvements}
\textbf{Malicious senders or receivers of Zcash:}
Senders or receivers of Zcash can act honestly within the protocol but
maliciously outside of the protocol (such as creating a ``honeypot'' for which
Zcash users are tricked into sending valid transactions to). Such an attack
would require the malicious receiver (or sender) to deanonymize the sender by
one of the following methods:
\begin{enumerate}
\item Gaining identifiable information from the transaction itself.
\item Using known network analysis methods to trace a transaction back to its
source.
\item Operating a node used as an entry point (such as a light wallet).
\end{enumerate}
While preventing malicious
senders or receivers of Zcash from compromising the other part is certainly
within the threat model of Zcash, we defer addressing this category of threats
for future improvements.
\textbf{Learning the tuple (sender or receiver identity, transaction):}
Note that a network observer can also gain a subset of sender/receiver
linkability information by
observing just a sender \emph{or} receiver's identity linked to a specific
transaction. Note this information is more valuable in an unshielded setting,
as learning the unshielded transaction can give the attacker useful
information. However, learning this information in a shielded setting simply
gives the attacker enough information to learn that they are sending a Zcash
transaction, but no additional information. As such, we consider this a
deferred threat that we can consider in the future.
\textbf{Partitioning attacks:} The Zcash network itself could be partitioned,
such that some nodes think they are aware of the entire network, but only
instead be aware of a small subset of nodes. Such attacks could be performed by
DNS seeders (again, by lying about the state of the network), or even by
highly-connected nodes. Such attacks are well-known in the literature and in
practice and demonstrated to be practical for small-scale networks without a
centralized mechanism for distribution about network state. However, we defer
this threat for future improvements, as it requires designing a
fully-decentralized but fully consistent network information distribution
mechanism.
\subsubsection{Out of Scope}
\label{out-of-scope}
\textbf{Unforeseen software flaws:} While our team at the Zcash Foundation
works diligently to prevent software bugs and vulnerabilities to the best of
our ability, we do not
consider such flaws in scope, as such cases are unforeseen
and we cannot rule them out completely. As such, when we become aware of
vulnerabilities or flaws, we will fix them, but we cannot claim such
occurrences will not occur in the future.
\textbf{User behavior Outside of the Zcash protocol:} Zcash is not used in a
vacuum; spending and receiving Zcash is linked to real-world value. As such, we
do not consider user behavior outside of the Zcash protocol to be in scope,
even if that behavior results in spending or receiving Zcash.
For example, someone who goes to a website and wishes to purchase an item in
Zcash may be unlinkable purely when observing the Zcash network, but their
behavior when browsing the website can still be observable to a network
attacker. In order to spend Zcash in a \emph{truly} private way, the user must
use another privacy-preserving technology to hide their spending behavior
outside of Zcash, such as accessing that website over Tor.
\textbf{Sybil attacks:} In small decentralized networks, adversaries can
control a larger percentage of the total network and consequently gain more
advantage over collective network functions. However, we do not consider such
attacks as in scope to our assessment; we assume an adversary with sufficiently
limited resources as to require participation akin to honest users.
\subsection{Attacks Less Applicable to Shielded Transactions}
\textbf{Epistemic attacks:} A network observer could perform an epistemic
attack by observing unique routing information that allows for eventual
deanonymization of that user. Again, such attacks are possible in Zcash because
users do not control routing information for their transaction.
One example of epistemic attacks against cryptocurrency networks involve the
probability of ``super-connected'' nodes that can link the node from which a
transaction originated~\cite{dandelion, fanti2018dandelion}.
However, in the case of a blockchain, all transactions are first synced to the
blockchain (and become part of the global state of the network) before the
receiver can learn the transaction. Hence, an adversary
will not be able to learn the sender, receiver, transaction tuple simply by
passively observing network traffic (unless the receiver is using a light
wallet, and this query is made in the clear).
\textbf{End-to-end timing fingerprinting attacks:}
While an adversary can perform timing fingerprinting attacks on the sender of a
transaction, the adversary still must be able to correlate this information to
the receiver of the transaction in order to learn the full tuple of value.
However, again, deanonymizing the receiver is possible
\emph{only} in the light wallet setting when shielded transactions are used, as
otherwise the receiving protocol is a full broadcast protocol.
While light wallets could attempt to perform end-to-end timing attacks to link
the sender and receiver of a transaction, we
consider such attacks out of scope considering the latency and batching that is
added in the time required for a transaction to be included into the
blockchain, as further described in Section~\ref{observations}.
\textbf{End-to-end behavior fingerprinting attacks:}
Fingerprinting user behavior such as the frequency and number of transactions
made could in theory allow for end-to-end linkability of senders and receivers
in the setting where light wallets are used.
For example, a malicious light wallet node could observe
the frequency and pattern of a user’s transactions, and build a pattern to
match against over time.
However, as described in Section~\ref{observations}, it is unclear how
end-to-end behavior correlation could occur in practice, even if an adversary has a
complete view of the network, as all transactions must first be
published to the blockchain before a receiver can receive the funds. At minimum, a
transaction will have the anonymity set of the size of one block, but this
assumes a transaction is immediately synced to the blockchain. In reality,
ordering is not preserved for transactions included in the blockchain relative
to when they were published to the network, due to proof of work
requirements or variances in network topologies.
\section{Review of Network Privacy Approaches}
\label{network-privacy-review}
Ideally, some of the attacks described in Section~\ref{attack-vectors} could be
mitigated by using a network privacy layer. We now review three
classes of network privacy approaches, and then in
Section~\ref{network-privacy-assessment}, determine how these approaches
address the existing described attacks against Zcash.
For brevity, we only review
Dandelion~\cite{Fanti:2018:DLC,BojjaVenkatakrishnan:2017:DRB},
Tor~\cite{tor-specification}, and
general-purpose Loopix-based mixnets~\cite{Piotrowska:2017:LAS}.
Further, we review private information retrieval (PIR) as a method which can be
used in conjunction with the above systems.
\textbf{Dandelion.}
Dandelion~\cite{BojjaVenkatakrishnan:2017:DRB} and
Dandelion++~\cite{Fanti:2018:DLC} is a lightweight gossip protocol aimed at
adding additional network privacy for
distributed networks such as cryptocurrencies. Dandelion protects against
\emph{passive}
deanonymization attacks, but does not consider active or targeted attacks. Such
passive deanonymization attacks could be conducted by a ``super node'' that has
a high degree of connections to other nodes (and could either be a single node
or a botnet where adversarial machines share information). As such, it is
assumed that this adversary is honest-but-curious, following the gossip protocol
but wishes to learn as much information about users as it can directly observe.
However, Dandelion++ does consider a stronger adversarial model where nodes are
allowed an arbitrarily-number of connections to other nodes (acting outside of the
Bitcoin gossip spec which only allows 8).
Both Dandelion variants follow a randomized design for how transactions are
gossiped to the network, differing from the Bitcoin design where nodes publish
transactions as widely as possible as quickly as possible. In the Dandelion
design, whenever a node receives a transaction from a neighbor, it
first flips a coin to determine if the traffic is sent to a single
neighbor (constituting the ``stem'' phase) or to all the node's connections
(constituting the ``fluff'' phase). Such an approach frustrates the ability for
a super node to link a specific transaction to the node which originally
published that transaction.
\textbf{Tor.}
Tor~\cite{tor-specification} is an anonymity network that today has over 2.5
million users and a network
size of over 6,500 nodes. Tor supports applications that require low latency,
such as browsing the Internet anonymously or streaming videos. In order to
support such a use case, Tor assumes that it is hard for network adversaries to
gain an end-to-end view and provide correlation attacks, such as by injecting
timing or dropping packets to test if the traffic it can view entering the
network is the same as the traffic it can view leaving the network.
Tor distributes its routing information (i.e, information about each relay) via
an authenticated document called the \emph{consensus}, which is signed by a
threshold number of trusted servers called \emph{directory authorities}. In
doing so, Tor ensures that all clients and relays have a consistent view of the
network. By distributing a global authenticated document to all network
participants, Tor avoids epistemic or routing attacks unlike completely
decentralized networks which cannot guarantee a user or relay's view of the
network is authentic or that all users fall within a global anonymity set.
\textbf{Loopix-based Mixnets.}
While a range of mix network designs have been introduced in the literature, in
this assessment we consider only those which instantiate the
Loopix~\cite{Piotrowska:2017:LAS} design, which provides improved latency
guarantees over prior designs. Similar to other mix network designs, Loopix
uses dummy packets and message delays in order to protect against adversaries
performing fingerprinting and end-to-end attacks of user traffic.
While Loopix specifies how messages are routed through a network, Loopix-based
networks still require safely distributing network information to users and
nodes. As one example, Katzenpost~\cite{katzenpost}, a mix network which implemented
Loopix, used a similar model to Tor
by leveraging trusted network authorities to sign and distribute the state of
the network. However, alternative network distribution mechanisms can be used,
but similarly may be subject to epistemic and path-routing attacks similar to
other distributed networks.
\textbf{Private Information Retrieval (PIR).}
Even though the above network anonymity systems disassociate a sender or
receiver's identity from the transaction, nodes can still observe which blocks
are being fetched and perform fingerprinting attacks using this information.
One mechanism that can be used in conjunction with network anonymity tools is
private information retrieval (PIR)~\cite{pir}, which allows users to query information
while preventing the service that hosts this information from learning the
query.
Note here we do not specify \emph{which} PIR design to use, we simply assume
the properties of a PIR implementation, for which the content of the user's
query is hidden from the service tasked with responding to that query.
\section{Assessment of Network Privacy Approaches to Zcash Privacy (Assuming
the Use of Shielded Transactions)}
\label{network-privacy-assessment}
We now review the extent to which Dandelion++, Tor, some generic PIR mechanism,
and a \emph{general-purpose} Loopix-based mixnet
protect against the existing network-based attacks against Zcash described in
Section~\ref{threat-model}.
Note again that we assume an attacker does not control either the sender or receiver
of funds, and assume the attacker is limited in resources such that they cannot
perform a Sybil attack.
We summarize our results in Table~\ref{network-zcash-assessment}, but describe
our findings here.
\textbf{Assumptions.} We assume the mixnet is a separate anonymity network
entirely, and is \emph{not} part of the cryptocurrency network
itself (meaning that the initiator of a transaction forwards this transaction
through the mixnet first before it is published to the cryptocurrency network).
We assume that the PIR mechanism is used by the user to look up transactions in
such a way that the node serving that transaction cannot infer the contents of
the user's query.
\begin{table}[t]
\caption{Effectiveness of network privacy mechanisms for Zcash
security and privacy, assuming the use of shielded transactions}
\label{network-zcash-assessment}
\footnotesize
\CIRCLE=protects against; \Circle=does not protect against;
$\bigstar$=Not a threat in this setting;
Mixnet=General-purpose Loopix-based routing tuned for lower-latency
applications such as messaging or web-application traffic.
DoS=Denial of Service;
On-Path Correlation=End to end correlation attacks where one node in the path
is participating in the attack.
\medskip
\begin{tabular}{ p{4.5em}| c | c | c | c | c | c | c}
& & & & & \multicolumn{3}{c}{PIR} \\
& Attack & Dandelion++ & Tor & Mixnet & Only PIR & Tor & Mixnet \\
\hline
\multirow{2}{*}{Full Node} & DoS & \Circle & \Circle & \Circle & \Circle & \Circle & \Circle \\
& On-Path Correlation & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\
& Block Access Pattern & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\
\hline
\multirow{2}{*}{Light Client} & DoS & \Circle & \Circle & \Circle & \Circle & \Circle &
\Circle \\
& On-Path Correlation & \Circle & \CIRCLE & \CIRCLE & \Circle & \CIRCLE & \CIRCLE \\
& Block Access Pattern & $\Circle$ & $\Circle$ & $\Circle$ & $\CIRCLE$ & $\CIRCLE$ & $\CIRCLE$ \\
\end{tabular}
\end{table}
\subsection{Analysis for Use of Full Nodes}
\textbf{Dandelion++.}
In the full node setting when shielded transactions are used, Dandelion++ does
not meaningfully change privacy
guarantees for users, as Dandelion++ provides privacy in the setting of a
super node with knowledge of the network graph. In other words, knowledge of
the originating node when using shielded transactions does not result in a
meaningful information leak without additional knowledge of the receiver.
Further, the protocol does not add any protection against denial of service
attacks or the ability for nodes to observe block access patterns.
\textbf{Tor.}
As previously discussed, in the setting where full nodes are used, the receiver cannot be linked
to a specific transaction, unless the receiver themselves is malicious and
colludes with other parties.
As such, the use of Tor does does not meaningfully change user privacy.
\textbf{General-Purpose Mixnet.}
While the use of a general-purpose mixnet raises the cost to an adversary to
conduct fingerprinting attacks that could result in end-to-end linking of
senders and receivers, this protection does not meaningfully increase user
security in the full node setting.
Most specifically, because receivers operate in a
full-broadcast mode, end-to-end linking of senders and receivers is not
possible when full nodes are used, unless the receiver themselves is
compromised or malicious.
\textbf{Only PIR.}
Because the receiver in a full node setting receives all transactions, use of
PIR does not add any additional meaningful protections when shielded
transactions are used. This is because the receiver has the full set of
transactions themselves and consequently will not expose a specific query to
any external party.
\textbf{Tor + PIR.}
Because receivers of Zcash when using a full node operate in full broadcast
receiver mode---meaning that the user
does not leak which transaction they are interested in---use
of PIR in this setting does not meaningfully add privacy or security
protections.
\textbf{General-Purpose Mixnet + PIR.}
Again, because users operate with full nodes, even though the sender's identity
is hidden and so are any timing or behavior leaks, use of mixnets with PIR does
not add meaningful security when shielded transaction are used.
\subsection{Analysis for Use of Light Wallets}
\textbf{Dandelion++.}
Similarly to the analysis for use of useful in a non-shielded context, Dandelion++ does not protect against
end-to-end correlation attacks in the setting where light wallets are used.
Specifically, while Dandelion++ protects against super nodes that can observe
in-network gossip messages, Dandelion++ does not provide ``last-mile'' privacy,
meaning that users can still be deanonymized by the light wallets they use.
\textbf{Tor.}
Tor protects against a light wallet directly distinguishing between receivers
in a light wallet setting, as the light wallet will not be able to learn the
network identity (IP address) of a receiver.
Because Tor is a low-latency
network, even if the receiver IP address is hidden from the light wallet, the
light wallet or a network observer can still observe the user's timing and
behavior when fetching transaction details. However, because a user's
transaction is published to the Zcash network, and then published as the next
block in the Zcash blockchain with a series of other transactions, it is
unclear how much of an advantage an adversary has to perform end-to-end
timing-based attacks in this setting (as further discussed in
Section~\ref{observations}). Typically end-to-end timing attacks
require performing packet correlation on the order of seconds, whereas the
latency in a network like Zcash is on the order of minutes. As such, we deem
timing-based attacks to be not applicable even when light wallets are used for
Zcash.
However, the light wallet can still observe which queries a receiver wishes to
fetch, even if the light wallet cannot observe that receiver's network
identity.
Hence, we do not grant the property of protecting against
block access patterns from receiver queries.
\textbf{General-Purpose Mixnet.}
Because blockchains require publishing transactions to a global immutable data
store (the blockchain), the property of mixnets to inject dummy packets to help
discourage end-to-end packet correlation in a web traffic setting is less
relevant in a blockchain setting.
Further, as described in Section~\ref{observations}, the ability of an adversary to use timing of
transactions to infer information about the sender, receiver, and
contents is less relevant in a blockchain setting due to the inherent latency
incurred when publishing a transaction.
While mixnets do hide timing information for packets by
delaying messages sent through the mix network, in general-purpose mixnets that
are tuned for web or
messaging application traffic, such
delays are on the order of seconds or even microseconds, where as we observed
above, the Zcash network itself imposes delays on the order of minutes as
transactions are added to the Zcash blockchain. Performing an end-to-end
correlation attack simply by observing the endpoints (nodes servicing the
sender or receiver of the transaction) will have difficulty performing such a
timing correlation even in Zcash today.
Similarly to the description of Tor above, a light wallet can observe which
queries a receiver wishes to fetch, and so a malicious light wallet could use
additional information to perform linking attacks. Hence, we do not grant the
property of protecting against block access patterns.
\textbf{Only PIR.}
PIR in the setting of Zcash ensures that a receiver can hide which transaction
they are interested in learning. However, a malicious on-path light wallet
could still perform end-to-end correlation attacks by observing the sender and
receiver's identities, as well as link the sender to a specific transaction.
Hence, we do not grant full protection against on-path correlation attacks when
only PIR is used. However, we do grant protection against the light wallet
observing block access patterns due to the use of PIR.
\textbf{Tor + PIR.}
In the setting where senders and receivers use Tor along with PIR, we grant a
full circle for protection against on-path correlation
attacks.
While nodes can learn that \emph{someone} is sending and receiving a
transaction, nodes cannot learn either \emph{which} transaction, \emph{nor} who
the sender or receiver are.
Again, block access patterns are protected against due to the use of PIR.
\textbf{General-Purpose Mixnet + PIR.}
We grant a full circle for protection against on-path
correlation attacks when a mixnet used in conjunction with PIR, as the use of
PIR should only increase protection to users.
Finally, block access patterns are protected against similarly to in the Tor +
PIR case.
\section{Future Improvements for Zcash Network Privacy}
\label{future-improvements}
\subsection{Network Privacy Improvements for Unshielded Transactions}
While the end goal for Zcash is to move all users to use shielded transactions,
the reality today is that only a very small percentage of Zcash is transacted
using shielded transactions. In the interim to achieving the goal of
ubiquitous shielded transactions, we can take intermediate steps to improve
the privacy for Zcash users in the unshielded setting.
With that said, incorporating a variant of the Dandelion++ gossip protocol is a
lightweight and immediate first step to improving the privacy of unshielded
transaction. However, we recognize that stronger protections are required in
following steps to provide stronger security and privacy guarantees.
\subsection{Network Privacy Improvements for Shielded Transactions}
In looking at Table~\ref{network-zcash-assessment}, the strongest protections
are offered by the combination of PIR along with a network anonymity tool such
as Tor or a mixnet. Because use of an anonymity network protects against
directly leaking the network identity of a user, and PIR protects against
disclosing the contents of a user's query, the combination of these methods
leaves little room for an attacker to gain advantage.
While typically the
ability for mixnets to offer protection
against timing or behavior fingerprinting attacks is desirable,
in the setting where shielded transactions are used along
with PIR for receiver queries, this advantage becomes minimal as mixnets tuned
for general application traffic (such as web traffic) will not meaningfully
increase end-to-end latency beyond that already induced by the blockchain
itself.
Again, this observation requires that the receiver can hide the contents of
their query.
As such, our immediate-term plan to proceed with Tor integration, and will
assess PIR as a second step.
We will continue to observe the development of production-ready mixnets as a
possible option in the future, with an eye towards large-scale adoption in
order to ensure sufficiently large anonymity sets for users.
\section{Conclusion}
\label{conclusion}
In this technical report, we sketched out a more formalized assessment for the
network privacy of
users of Zcash, and identified how this threat model differs between a setting
where users exchange shielded versus unshielded transactions. We then assessed
the extent to which well-known network anonymity tools improve protections for
Zcash users in the setting where \emph{shielded} transactions are used.
Finally, we described next steps to improve user privacy in both a shielded and
unshielded setting, starting with lightweight improvements to further
longer-term structural changes.
\section{Acknowledgements}
We would like to thank Holmes Wilson from Zbay for his insightful discussion
and feedback on this technical report.
\bibliographystyle{plain}
\bibliography{network-privacy}
\end{document}