805 lines
40 KiB
TeX
805 lines
40 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.
|
|||
|
|
|||
|
\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}
|