823 lines
41 KiB
TeX
823 lines
41 KiB
TeX
\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.
|
||
|
||
\subsection{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.
|
||
|
||
|
||
\subsection{Tor.}
|
||
\label{tor-intro}
|
||
|
||
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.
|
||
|
||
In Zcash, Tor integration can be implemented at several points: between senders
|
||
and the Zcash network, between Zcash peers, or between receivers and the Zcash
|
||
network. Because our focus is on preventing \emph{end-to-end} correlation
|
||
attacks, we focus our attention on integrating Tor to submit and receive
|
||
transactions only. While integrating Tor between Zcash peers could have some
|
||
utility, as demonstrated by our analysis, this protection can easily be
|
||
circumvented by malicious peers handling entry/exit traffic to the network.
|
||
|
||
|
||
\subsection{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.
|
||
|
||
\subsection{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 between senders and receivers and the edges of the Zcash
|
||
network. 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 to facilitate
|
||
sending and receiving transactions over Tor, and will
|
||
assess PIR to improve receiver query privacy 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.
|
||
|
||
As discussed in Section~\ref{tor-intro}, sending Peer-to-Peer traffic between
|
||
Zcash nodes may frustrate some attackers' ability to perform end-to-end
|
||
correlation attacks, but has no effect on other adversaries such
|
||
as malicious light wallets. As such, we deem integrating Tor in the P2P gossip
|
||
protocol for Zcash as low priority.
|
||
|
||
\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}
|