chap04-sec01.tex

% !TEX root = ../zeth-protocol-specification.tex

\section{Client security considerations}\label{client-security}

In this section we consider some details of client \emph{wallet} software that manages user's private and public keys, \zeth{} notes, and interacts with the $\mixer$ contract.

Due to the processing and storage requirements involved, we consider it impractical for all \zeth{} client implementations to assume that a dedicated $\ethereum{}$ node (miner node or archive node) is run on the same host as the wallet. Therefore, in order to interact with the $\ethereum{}$ network, wallet software must communicate with external $\ethereum{}$ P2P nodes via their RPC channel, and must assume that these nodes are completely outside the wallet's control. \emph{From a security standpoint, connected $\ethereum{}$ nodes should therefore be considered untrusted, and in particular the details of all RPC calls and responses should be considered publicly visible}. Note that even if the connected $\ethereum{}$ node itself is not malicious, 3rd parties able to see network traffic may also be able to gain an insight into the RPC communication of a specific \zeth{} client.

\begin{notebox}
    Note that there are several possible models besides the fully untrusted $\ethereum{}$ node. Organizations or individuals could host one or more ``trusted'' $\ethereum{}$ nodes, which clients can securely connect to (if they trust the host). This centralization would represent a security trade-off. From the point of view of clients it would create a single point of trust, and for potential malicious observers or attackers it would represent a valuable target.
\end{notebox}

In what follows we focus on preventing data leaks through network traffic. We do not consider adversaries with physical access to the machine running the wallet (see~\cref{appendix:sca-attacks}).

\begin{notebox}
    Importantly, we focus here on information leakages intrinsic to network communication patterns of the \zeth{} protocol. However, in order to protect against sophisticated adversaries, it is necessary to use network-level anonymity solutions to protect the source of messages emitted on the network. While this is outside of the scope of the $\zeth{}$ protocol, we highly encourage implementers to establish threat models and consider using technologies like \emph{mixnets} to protect against network analysis (see e.g.~\cite{DBLP:conf/uss/PiotrowskaHEMD17,DBLP:conf/sp/DanezisG09}).
\end{notebox}

\subsection{Syncing and waiting}\label{client-security:syncing}

\zeth{} clients must periodically synchronize with the latest state of the blockchain. This is necessary to keep track of the data held by the $\mixer$ contract, and to detect notes received by the user of the wallet, storing them for future transactions.

Clients should synchronize with $\ethereum{}$ nodes in such as way that information is not leaked. As such:
\begin{enumerate}
    \item Clients \MUST{} use consensus evidence and block headers to verify all data they receive from $\ethereum{}$ nodes.
    \item Clients \MUST{} locally store all parts of the $\mixer$ state they require in order to function.
    \item Clients \MUST{} obtain all such information by ``synchronizing'' with the $\ethereum{}$ blockchain and parsing relevant events emitted by $\mixer$. Clients \MUSTNOT{} query the $\mixer$ state via RPC.
    \item Clients \SHOULD{} take steps to avoid being identified while synchronizing (see~\cref{appendix:sca-attacks:synchronization}. For example, clients \SHOULD{} vary the set of $\ethereum{}$ nodes that they connect to, and \SHOULDNOT{} always sync from the block following the last one that they processed.
    \item Clients \SHOULDNOT{} re-request blocks or transaction receipts that are of particular interest to them. They \SHOULD{} process all events, emitted by $\mixer$, in the same way.
    \item Clients \SHOULDNOT{} make any RPC calls or change their externally visible behaviour in response to blocks or transaction receipts that are of interest to them.
\end{enumerate}

\subsubsection{Use of contract queries}\label{client-security:syncing:client-queries}

We suggest that clients \SHOULDNOT{} directly query the contract state, for the reasons discussed in~\cref{appendix:sca-attacks:synchronization} and~\cref{appendix:sca-attacks:successful-decryption} (and consequently,~\cref{contract-security} suggests that the \mixer{} contract should, as far as possible, not expose public methods). The $\zeth{}$ protocol prohibits direct queries of the state of $\mixer{}$ (via \emph{public} smart-contract functions) because they introduce a risk that client implementations will leak information by using them.

If implementers choose to add public methods to the \mixer{} contract (for application-specific reasons), they should consider carefully the security issues raised in \cref{appendix:sca-attacks}. This specification assumes that \mix{} is the only public method of the \mixer{} contract.

\subsection{Note management}\label{client-security:syncing:note-management}

$\mix$ calls on the $\mixer$ contract emit log events containing new commitment values, nullifiers, the new Merkle root and the secret data for new notes (encrypted using a key derived from the recipients public key). As clients synchronize with the latest state of the blockchain, they \MUST{} read these events and correctly process the data they contain.

\begin{enumerate}
    \item Clients \MUST{} process the $\mixEventDType$ event for every $\mix$ transaction, in the order in which they appear in the blockchain.
    \item Clients implementing spending functionality \MUST{} use the commitment values in events to track the state of the Merkle tree. The Merkle tree state will be used to generate Merkle paths for future transactions, and \MUST{} be made available to the client without the need to query the contract. (Note that not all commitments must necessarily be persisted -- see \cref{implementation:efficiency}).
    \item Clients that can receive notes \MUST{} attempt to decrypt the ciphertexts for every transaction (see \cref{zeth-receive:decrypt} in \cref{zeth-protocol:zeth-receive}).
    \item Clients \MUSTNOT{} perform any network-related action, including closing the RPC connection, dependent on successful/unsuccessful decryption of ciphertexts (see \cref{appendix:sca-attacks:successful-decryption}).
    \item Clients that can receive notes \MUST{} attempt to parse any successfully decrypted plaintext (that is, ensure it is well-formed as in \cref{zeth-receive:parse-plaintext} in \cref{zeth-protocol:zeth-receive}).
    \item Clients \MUSTNOT{} perform any network-related action, including closing the connection, dependent on successful / unsuccessful parsing (see \cref{appendix:sca-attacks:invalid-ciphertext}).
    \item Clients that can receive notes \MUST{} verify that successfully parsed plaintext data is the opening of the corresponding commitment in the transaction (see \cref{zeth-receive:check-note-data} in \cref{zeth-protocol:zeth-receive}).
    \item Clients \MUSTNOT{} perform any network-related action, including closing the connection, dependent on whether the parsed note data is the opening of the corresponding commitment (see \cref{appendix:sca-attacks:invalid-ciphertext}).
    \item Clients \MUST{} confirm that, after adding the new commitments, the local representation of the Merkle tree of commitments has a root consistent with the event data.
    \item Clients \SHOULD{} keep a \emph{local} record of the data related to valid decrypted notes. This will be required in order to spend the notes in a future transaction.
    \item Clients implementing spending functionality \SHOULD{} process all nullifiers in $\mix$ transaction events, checking for any corresponding notes previously recorded. Any such note should be marked as spent in the client's local record.
\end{enumerate}

\subsection{Prepare arguments for $\mix$ transaction}

Clients \MUSTNOT{} query $\ethereum{}$ nodes while generating any arguments to a $\mix$ call. In particular, Merkle paths \MUST{} be calculated using the client's local representation of the Merkle tree of commitments that was constructed by parsing events.

Where the zero-knowledge proof is generated by some external process, clients \MUST{} put in place sufficient security schemes to ensure that:
\begin{itemize}
    \item they are communicating with an authentic proof generation process (not a man-in-the-middle), and
    \item data sent to and from the proving process cannot be observed in transit and tampered with by a third party, and
    \item the proof has been generated for the correct instance--witness pair\footnote{Although given an acceptable zk-proof $\pi$ for an instance $\priminputs$ it is infeasible to check which witness has been used -- which comes directly from the zero-knowledge property -- we need to assure security measures that prevents any third party from mauling and tampering with the proof generation process.}
  \end{itemize}

Without these safe-guards, the operation of the system and the secret data required to spend the input notes may be compromised. See~\cref{appendix:sca-attacks:proof-generation}.

\subsection{Wallet backup and recovery}\label{client-security:wallet-backup-and-recovery}

Given the restrictions placed on clients and their interaction with the \mixer~contract, it follows that clients must store all data required to spend notes owned by their users' addresses, and to verify the validity of incoming notes. If this local data is lost, it must be reconstructed before client operations can resume.

\zeth{} private keys (see~\cref{preliminaries:tab:dap-privaddr}) can be used to fully restore client state. In this case, clients \MUST{} retrieve all events from the beginning of the \mixer~contract's history, decrypting notes and tracking nullifiers, as described in the previous sections, to reconstruct the set of unspent notes that they own.

Without a backup of the private keys it is not possible to restore wallet state. As such, private keys are the minimal set of data that must be securely stored and backed up, and clients \SHOULD{} provide support for this mode of recovery. However, to avoid the need to scan all events emitted by \mixer{} (a very expensive operation) implementations \SHOULD{} also support back ups of further state data (such as the representation of the Merkle tree of note commitments, the set of unspent notes, etc) to allow more efficient modes of recovery.