Remote Side-Channel Attacks on Anonymous Transactions Florian Tramer and Dan Boneh, Stanford University; Kenny Paterson, ETH Zurich https://www.usenix.org/conference/usenixsecurity20/presentation/tramer

This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5

Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. Remote Side-Channel Attacks on Anonymous Transactions

Florian Tramèr∗ Dan Boneh Kenneth G. Paterson Stanford University Stanford University ETH Zürich

Abstract Bitcoin’s transaction graph. The same holds for many other Privacy-focused crypto-currencies, such as Zcash or Monero, crypto-currencies. aim to provide strong cryptographic guarantees for transaction For those who want transaction privacy on a public confidentiality and unlinkability. In this paper, we describe blockchain, systems like Zcash [45], Monero [47], and several side-channel attacks that let remote adversaries bypass these others offer differing degrees of unlinkability against a party protections. who records all the transactions in the network. We focus We present a general class of timing side-channel and in this paper on Zcash and Monero, since they are the two traffic-analysis attacks on receiver privacy. These attacks en- largest anonymous crypto-currencies by market capitaliza- able an active remote adversary to identify the (secret) payee tion. However our approach is more generally applicable, and of any transaction in Zcash or Monero. The attacks violate we expect other anonymous crypto-currencies to suffer from the privacy goals of these crypto-currencies by exploiting similar vulnerabilities. side-channel information leaked by the implementation of Zcash and Monero use fairly advanced cryptographic different system components. Specifically, we show that a primitives such as succinct zero-knowledge arguments (zk- remote party can link all transactions that send funds to a SNARKs) [5] and ring signatures [43]. Despite these strong user, by measuring the response time of that user’s P2P node cryptographic protections, some protocol-level attacks on to certain requests. The timing differences are large enough transaction privacy have been found [4, 28, 37] and corrected that the attacks can be mounted remotely over a WAN. We (we discuss these attacks in the related work in Section7). responsibly disclosed the issues to the affected projects, and In this paper we take a different approach to analyzing the they have patched the vulnerabilities. privacy guarantees for anonymous transactions. Rather than We further study the impact of timing side-channels on attacking the abstract protocols, we look at side-channel in- the zero-knowledge proof systems used in these crypto- formation that is leaked by the implementation of different currencies. We observe that in Zcash’s implementation, the components in the system. Specifically, we look at timing side- time to generate a zero-knowledge proof depends on secret channels and traffic patterns, as measured by a remote network transaction data, and in particular on the amount of transacted attacker. We show that, while the abstract zero-knowledge funds. Hence, an adversary capable of measuring proof gen- protocols used in these systems can hide information from eration time could break transaction confidentiality, despite an observer, these protocols are vulnerable to side-channel the proof system’s zero-knowledge property. leakage. Any information leakage can invalidate the zero- Our attacks highlight the dangers of side-channel leakage in knowledge property, and weaken or break the privacy guaran- anonymous crypto-currencies, and the need to systematically tees of anonymous transactions. protect them against such attacks. 1.1 Our results 1 Introduction We describe multiple attacks on transaction privacy in Zcash and Monero that exploit communication patterns or timing Bitcoin, the largest crypto-currency, is not private: several aca- information leaked by different parts of the system. We take demic studies [2,24,34,42,44] and multiple commercial prod- a systematic approach, looking at the life cycle of an anony- ucts [11,12,23] show that one can effectively de-anonymize mous transaction as it traverses the system. At every step, we ∗Part of this work was performed while the first author was visiting ETH look for side-channels and asses their impact on user privacy. Zürich. The life-cycle of an anonymous transaction is shown in

USENIX Association 29th USENIX Security Symposium 2739 ① User creates Tx ② Tx is sent into P2P network ③ Wallets process new Txs

Wallet with local prover Wallet with local node

π

Wallet with remote prover Wallet with remote node wallet π

Adversary 1a P2P node Adversary 2 Adversary 3 Adversary 1b

Figure 1: Side-channels in the anonymous transaction life cycle. (1) A user’s wallet creates a transaction, which involves generating a cryptographic proof. This computation might be performed locally or outsourced to a remote service. (2) The wallet sends the new transaction to a P2P node which propagates it into the network. (3) A P2P node shares a received transaction with a connected wallet; the connection may be local or remote. During transaction creation, Adversary 1a can time an outsourced proof generation to leak some transaction secrets (Section 3.3). When processing a new transaction, a wallet’s behavior may change when it is the transaction’s payee. If the wallet connects to a remote node, this can be inferred by Adversary 1b that observes traffic patterns between the wallet and node, or by Adversary 3 that controls the node. If the wallet and node are co-located, changes in the wallet behavior can be inferred by Adversary 2 that interacts with the user’s P2P node (Section 3.2).

Figure 1. First, the transaction is created in the payer’s wal- node was the transaction’s payee or not. This constitutes a let, possibly with the help of a remote server to generate the break of transaction unlinkability. necessary zero-knowledge proof to prove transaction validity. In the second case, we propose the REJECT attack wherein Then the transaction is transmitted through the P2P network. an attacker carefully crafts a malformed transaction, encrypts Finally, the transaction is received by the payee wallet, pos- it under a known (but anonymous) public key, and sends it to sibly with the help of a remote P2P node that records all a target P2P node. If decryption succeeds, then the exception transactions in the P2P network. The payee’s wallet must is triggered, and the target node sends an explicit “reject” scan through all anonymous transactions in the network to message back to the attacker. Receipt of this message then find those transactions of which it is the recipient. tells the attacker that the selected public key belongs to the An attacker can observe side-channel information at each owner of the target P2P node — a breach of anonymity. of these steps and attempt to learn information about the Details of the PING and REJECT attacks are in Section4. transaction, such as: the identity of the intended payee (e.g., their public key, or the IP address of their P2P node), the amount of funds transferred in the transaction, or the source Monero. For Monero, where wallets and nodes are run in of the funds. We next summarize our results. separate processes, we show that receipt of a payment alters the communication pattern between a wallet and its node. If the wallet is connected to a remote node (as is common for Zcash. In Zcash, a user’s wallet and P2P node are run in a mobile wallets or when first syncing with the network), we single process. The wallet checks if it is the payee of every in- show in Section5 that a passive network adversary can infer coming transaction by attempting to decrypt it using its secret if the wallet is the payee of a recent transaction. Furthermore, key. This results in two sources of side-channel leakage: (1) even if the user’s wallet and node are co-located, we show if decryption succeeds and the decrypted transaction (called a that a remote adversary can infer the wallet-to-node commu- Note plaintext) is well-formed, the wallet performs an extra nication pattern by causing and observing lock contention Pedersen commitment check; (2) if decryption succeeds, but over the node’s resources. We validate this timing attack in a the decrypted transaction is malformed, the wallet throws an WAN, where an attacker (located in London) infers if a victim exception that is propagated to the node’s P2P layer. (running a node and wallet in Zürich) receives a payment. In the first case, the time taken to perform the extra Ped- ersen commitment check causes a delay in the P2P node’s For both Zcash and Monero, our attacks enable a remote response to subsequent network messages. Consequently, we adversary to link anonymous transactions by identifying the show an attack, termed PING, which sends a transaction to a P2P node of each transaction payee. As described in Sec- node followed immediately by a “ping” message (a standard tion 3.2, the attacks can be further exploited to: (1) identify keep-alive message in Zcash’s P2P network). The attacker the IP address of a user’s P2P node, given her public key; (2) can use the delay in the ping response to infer whether the break the unlinkability of diversified addresses belonging to

2740 29th USENIX Security Symposium USENIX Association the same user. For Zcash, the attacks further enable to: (3) re- These crypto-currencies build on top of Bitcoin’s so-called motely crash a Zcash node, given the user’s public key, and (4) UTXO model. Each transaction spends outputs from prior create a remote timing side-channel on an (non constant-time) transactions and produces new outputs. The set of “unspent ECDH key-exchange involving the user’s long-term secret transaction outputs” (UTXOs) is recorded in a blockchain, viewing key, which potentially results in leakage of that key. and represents the total currency in circulation. These attacks can put privacy-conscious crypto-currency Each user of the currency possesses one or more public keys users (e.g., whistle-blowers or activists) at risk. For example, (also known as addresses), and connects to a P2P network to an adversary that links a user’s anonymous public key to her send and receive transactions. P2P node could uncover the user’s physical identity or loca- tion. An adversary that breaks unlinkability — and monitors Privacy goals. In Bitcoin, a UTXO is a tuple of the form transactions as they enter the P2P network — can infer which (amount,pk), where pk is the recipient’s public key. To later P2P nodes belong to users that are transacting with each other. spend this UTXO, the recipient produces a signature under The vulnerabilities we uncover and exploit run deeper than the corresponding secret key. A transaction thus reveals the the cryptographic timing side-channels exploited in prior amount of spent currency, the origin of funds (i.e., which work (e.g., Kocher’s attack [29] and subsequent remote timing UTXOs are spent), and their destination (i.e., the public key attacks on TLS [8,9]). Indeed, even if all the cryptographic of the owner of the new UTXOs). Moreover, a user’s public primitives in Zcash or Monero were constant-time, the attacks key can be linked to the P2P node that she connects to when described above would still apply (except for the timing at- sending transactions into the network. tack on the ECDH key exchange). This is because our main Currencies such as Zcash and Monero aim to provide the attacks exploit a lack of constant-timeness at the protocol following stronger privacy guarantees: level, whereas prior literature mainly studies cryptographic • Confidentiality: A transaction does not reveal the trans- constant-time guarantees at a lower-level algorithmic level. acted amount.

Side-channels in zkSNARK generation. In Section6 we • Untraceability: When a transaction spends a UTXO, it is look at timing side-channels at transaction creation time, hard to identify the transaction that produced that UTXO. where the payer generates a zkSNARK to prove that the trans- • Unlinkability: Given two transactions sent into the net- action is valid. We observe that in Zcash, the time to generate work (at most one of which is sent by the adversary), the a zkSNARK is not constant, but depends on secret information adversary cannot tell whether they pay the same address. such as the Hamming weight of the transaction amount. Our Moreover, given two addresses, an adversary cannot de- experiments show that the current implementation is therefore termine whether they belong to the same user.1 not zero-knowledge in practice: the information gleaned from timing leakage invalidates the zero-knowledge property. An • User anonymity: Given a user’s address (i.e., a public adversary can extract this information if it can measure the key), an adversary cannot determine how the owner of running time of the zkSNARK generation procedure. How- that address is connected to the P2P network. ever, as we explain in Section 3.3, it may be difficult to exploit this leakage in the current Zcash system. Privacy techniques. These privacy guarantees are achieved via a combination of cryptographic techniques, which we informally describe next. 1.2 Disclosure and remediation. Confidential transactions [33] hide the amount of trans- All the vulnerabilities discussed in this paper were disclosed acted funds. A confidential transaction’s UTXOs are of the to Zcash and Monero, and have subsequently been fixed in form (Commit(amount),pk), i.e., they only reveal a crypto- recent versions of both projects [17, 20, 22, 35]. graphic commitment to the transacted amount. The transac- We hope that this work will help inform other privacy- tion further includes a proof that its total balance is zero. oriented blockchain projects about the dangers of side- UTXO anonymity sets provide untraceability by concealing channel leakage in anonymous payment systems. It should the identity of a transaction’s inputs. Specifically, an anony- also motivate the development of constant-time implementa- mous transaction does not reveal the UTXOs it spends, but tions of cryptographic primitives such as zkSNARK provers. only a super-set of UTXOs along with a zero-knowledge proof of ownership of some UTXOs in this set. Obfuscated and diversified addresses guarantee unlinka- 2 Architecture of an Anonymous Payment bility. To prevent linkability of transactions sent to the same System 1The latter property enables a user to receive payments from different entities without those entities knowing that they are paying the same user. This section introduces some core design concepts of privacy- This can be trivially done if the user maintains multiple public-key pairs. A focused crypto-currencies such as Zcash and Monero. more efficient solution is given by diversified addresses, described hereafter.

USENIX Association 29th USENIX Security Symposium 2741 address, the UTXOs of anonymous transactions contain an The anonymous transaction life-cycle. Figure1 illus- “obfuscated” public key (e.g., a commitment to the key in trates how anonymous transactions are created and shared Zcash). Diversified addresses (or sub-addresses in Monero) with nodes and wallets via a P2P network: enable a user to anonymously transact with multiple entities, 1. To send a new transaction, a user’s wallet selects some without managing multiple secret keys. From a single secret UTXOs and produces a zero-knowledge proof of validity key sk, users can create multiple public keys pk1,...,pkn. for the transaction. These keys are unlinkable: it is hard to determine whether two public keys pk,pk0 are derived from the same secret key. 2. The transaction is sent to the P2P node connected to the Blockchain scanning is a technical consequence of unlinka- wallet and shared with the network. P2P nodes store these bility. Since an anonymous transaction’s UTXOs do not reveal transactions in their “Memory Pool” (Mempool). the recipient’s public key in the clear, users have to scan every 3. P2P nodes share these transactions with connected wallets. new transaction and perform various cryptographic operations A wallet scans every new transaction to check whether it to check whether a transaction is intended for them. is the transaction’s payee. User anonymity is guaranteed by untraceability and unlink- Steps 2 and 3 are also performed once a transaction is ability. Since a transaction reveals nothing about the sender’s included in a block. When a block is mined, the block and the or receiver’s public key, a user’s public key cannot be linked transactions it contains are propagated to all P2P nodes. The to the P2P node that she uses to send or receive transactions. block’s transactions are then shared with user wallets.

Software deployments. Deployments of crypto-currency software differ across projects (and among users of the same 3 Overview of the Attacks currency). Various deployment choices greatly influence a user’s vulnerability to the side-channel attacks we present. This section gives an overview of our attack strategies. Sec- We distinguish three types of software: (1) Nodes are P2P tion4,5 and6 then describe instantiations and evaluations of clients that handle the blockchain’s consensus layer by ex- these attacks in both Zcash and Monero. changing and validating transactions and blocks; (2) A wallet (possibly backed by a hardware module) stores a user’s keys 3.1 Threat Model and UTXOs and connects to a node to send or receive transac- tions. (3) A prover produces the zero-knowledge (ZK) proofs The attacks described in this paper are remote side-channel required to privately spend a user’s UTXOs. attacks. We thus never assume that a victim’s software is com- 2 We consider the following common deployment modes, promised. In line with the software deployments described which refer to the interaction between a user’s wallet and a in Section2, we consider the following remote adversaries, P2P node or prover. which are illustrated in Figure1. 1. Integrated. The wallet, node and prover functionalities 1. A network adversary (Adversary 1a and 1b in Figure1) are all part of the same process. This is the current design passively monitors the encrypted traffic between a vic- of the official Zcash client. tim’s wallet and a remote service (e.g., a node or prover). 2. Local. Different components are run in separate processes 2. A P2P adversary (Adversary 2) participates in the P2P in a local network (this is Monero’s default for wallets network. The attacker may deviate from the P2P protocol. and nodes). Some hardware wallets also delegate the gen- 3. A remote node adversary (Adversary 3) controls a third- eration of cryptographic proofs to a local software. party P2P node and passively monitors the (plaintext) 3. Remote owned. Due to restricted computation power or communication between a victim’s wallet and this node. memory, a wallet may connect to a remote P2P node or prover hosted by the user. Remote P2P nodes are com- 3.2 Attack Type I: Side-Channels at the Re- monly used, e.g., in Monero or Zcash’s mobile wallets. Outsourcing cryptographic proofs is uncommon, but is ceiving Party explicitly enabled in Zcash’s design [27] and was imple- The most practical and pervasive side-channel attacks that we mented in an earlier protocol version [15]. discovered affect the last stage of the anonymous transaction 4. Remote third-party. As running a P2P node is costly, users life-cycle depicted in Figure1 — when a wallet processes may connect their wallet to a node hosted by a third party. new transactions. These attacks enable remote adversaries to This is common in Monero: newly created wallets connect break the system’s unlinkability and anonymity guarantees. to third party nodes while a local node downloads the 2An adversary co-located with a user’s wallet could resort to more power- blockchain. Such a deployment is unlikely for ZK provers ful attacks (e.g., cache side-channel attacks). However, such adversaries are as the third-party prover has to be trusted for privacy [27]. explicitly outside of the threat model considered by Monero and Zcash [18].

2742 29th USENIX Security Symposium USENIX Association Our attacks exploit prevalent design flaws in the way that Attack strategies. Our attacks exploit a difference in the a user’s wallet periodically checks whether it is the payee of way that a wallet processes a transaction when it is the payee any new transactions. and when it is not. This difference is due to additional crypto- graphic operations performed to retrieve received funds. Such differences in wallet behavior are not an issue per se, Attack goals. Our attacks target transaction unlinkability as a remote attacker cannot directly interact with a user’s wal- and user anonymity. The attacker’s goals are thus to: (1) de- let. Yet, we find that due to various design flaws, differences termine whether two transactions pay the same address, and in wallet behavior impact the interactions between the wallet (2) to determine how the user of a known address connects to and its P2P node. In turn, we show that a remote attacker can the P2P network. infer changes in the wallet-to-node interactions via various Our attacks are tailored to common deployment of wallets side-channels. We develop two general attack strategies: and P2P nodes. The actual goal achieved by all of our attacks is to identify the P2P node that is being used by the payee of • Strategy 1: Traffic analysis of wallet-to-node communica- a transaction. In a setting where multiple users connect their tion. If a wallet connects to a remote node, a network adver- local wallet to a shared remote P2P node, the attacks mounted sary or remote node adversary can passively observe changes by a network adversary or by a remote node adversary further in the wallet-to-node interaction. recover the actual wallet used by the transaction payee. We consider two different attack scenarios: • Strategy 2: Inferring wallet behavior from the P2P layer. If the wallet and node are co-located, a remote adversary cannot • The adversary knows an anonymous public key and sends observe their interactions. Nevertheless, if changes in wallet a transaction to this key to determine which P2P node (or behavior impact the interactions between the user’s P2P node wallet) the key’s owner uses to receive transactions. and remote peers, information still leaks to the adversary. • An honest user sends a transaction for which the adversary Both strategies apply not only when a transaction is created does not know the intended payee or her public key. The and sent into the P2P network, but also when it is included adversary determines which P2P node (or wallet) is used in a block. At that point, the block and all its transactions are by the transaction’s payee. shared with each peer, and wallets re-process the transactions The latter attack scenario subsumes the first, as the adver- to ensure they are valid (e.g., they did not double spend). sary can send honestly crafted transactions to a known public key. The latter scenario directly leads to a break of transaction unlinkability. Given two transactions sent into the network, 3.3 Attack Type II: Side-Channels at the the adversary simply determines whether the payees of both Sending Party transactions use the same P2P node or wallet. In addition, both attack scenarios represent a break of user anonymity and The attacks described in Section 3.2 — which break transac- can be bootstrapped for additional privacy violations: tion unlinkability and user anonymity — exploit flaws in the system design of P2P clients and wallets. As such, they do not • IP address recovery. The adversary can link a public key directly target any of the protocol’s cryptographic protections. to the IP address of the owner’s P2P node (or her wallet To broaden the scope of our investigation of side-channel vul- if it connects to a remote node), unless the owner uses 3 nerabilities in anonymous transactions, we initiate a study of anonymization tools such as Tor. This information can attacks on the cryptographic tools that guarantee confidential- be used to de-anonymize or geo-localize the victim. ity and untraceability at transaction creation-time — specifi- • Diversified address linkability. Given two public keys, an cally succinct zero-knowledge arguments (zk-SNARKs). attacker can determine if they belong to the same user or The attacks in this section are of a more conceptual nature. not. The attacker sends a transaction to each public key, While they are less likely to affect current users, these attacks and checks if the same node or wallet is identified. This illustrate once more the importance of having side-channel- breaks the unlinkability property of diversified addresses. free cryptographic implementations for future-proof and in- depth security of anonymity-preserving systems. • Private key recovery. The vulnerabilities underlying some of our attacks also open avenues for extracting a victim’s Attack goals. The transaction sender is responsible for en- secret “viewing” key via timing side-channels. Theft of suring confidentiality and untraceability. As we argue below, this key lets the adversary passively link all transactions the most plausible target for a remote attack is to recover sent to the victim (but not steal the victim’s funds). transaction amounts — thereby breaking confidentiality. 3An attacker who obtains a victim’s public key does not necessarily know the victim’s IP address. The victim could have shared the key using a third party messaging system or forum. An attacker might also have obtained some Challenges. Remote side-channel attacks on transaction public keys by hacking a service supporting anonymous transactions. creation face a number of challenges:

USENIX Association 29th USENIX Security Symposium 2743 1. Non-interactivity: Users can create transactions without transactions are created at a fixed time. An adversary may interacting with any other parties. also have the ability to trigger a transaction as part of some outer protocol. We draw a connection to timing 2. Ephemeral secrets: Many transaction secrets (e.g., trans- side-channels for digital signatures. While signatures are action amounts, and secrets related to UTXOs) are single- non-interactive, protocols that use them (e.g., TLS) can use. Thus, even if a side-channel exists, an adversary gets introduce remote side-channels [8,9]. a single attempt at extracting these secrets. Due to the high-entropy of many transaction secrets, our at- 3. High-entropy secrets: Long-lived secrets used in creating tacks target the transacted amount, a non-cryptographic value transactions (e.g., the user’s secret key) have high-entropy, for which even a coarse approximation (as leaked by a single and require a high-precision side-channel to be extracted. timing measurement) constitutes a privacy breach.4 We show that these challenges can be overcome by an adversary that targets the proving phase of the transaction creation process and that aims to (partially) recover a transac- Attack strategy. We consider a cryptographic timing at- tion’s confidential amount. tack that exploits timing variations in arithmetic operations depending on the operands’ values. Such attacks have been studied for many cryptographic primitives [8,9, 29], but had SNARKs in anonymous transactions. Zero-knowledge not been considered for zk-SNARKs prior to this work. proofs are a fundamental building block for anonymous trans- We exploit the fact that the time to produce a proof is cor- actions. In a zk-SNARK protocol, a prover has some secret related with the value of the prover’s witness. As the witness input (called a witness), and convinces the verifier that this contains the transaction amount, we expect this amount to be witness satisfies a given predicate, without revealing anything correlated with the proof time. For example, Zcash’s proofs else about the witness. In Zcash and Monero, such proofs cer- decompose the transaction amount into bits and compute an tify the validity of transactions while preserving their privacy. elliptic curve operation for each non-zero bit. The proof time In Zcash for example, a proof witness contains a list of spent is thus strongly correlated with the Hamming weight of the UTXOs, a receiver address, and a transacted amount, and the transaction amount, which is in turn correlated with its value. proof guarantees that these UTXOs exist and belong to the spender, and that all funds are transferred to the receiver. 4 Attacks on Unlinkability and Anonymity in Timing side-channels in zk-SNARK provers. Our thesis Zcash is that in current implementations, the time taken to produce a proof leaks information about the prover’s secret witness— We now evaluate the side-channel attacks on transaction pro- and in particular about the amount of currency being spent. cessing described in Section 3.2. We first demonstrate attacks Yet, as noted above, it may be hard for a remote adversary against Zcash. Attacks on Monero are described in Section5. to obtain a timing side-channel on the proof generation pro- Our attacks on Zcash adopt the second strategy from Sec- cess, due to the non-interactive nature of transaction creation. tion 3.2, that exploits a lack of isolation between a user’s Worse, timing a proof generation may be insufficient to ex- wallet and P2P node to leak wallet behaviors to a remote tract secrets that are ephemeral or have high-entropy. Despite P2P adversary. In the Zcash client, the two components are these challenges, we argue below that remote timing attacks part of a single process that sequentially processes received on zk-SNARK provers in anonymous crypto-currencies are messages (including new transactions). We describe two side- possible in some deployment scenarios, and we demonstrate channel attacks that exploit this tight coupling. Throughout in Section6 that the timing of a proof generation can leak this section, we often use the term “node” to refer to the single significant information about secret transaction amounts. process that implements both a P2P client and a wallet. Regarding non-interactivity, we make two observations: • If a weak client (e.g., a mobile wallet) outsources proofs to a remote service, a network adversary can time the prover. 4.1 Unlinkability in Zcash While proof outsourcing is uncommon, the Zcash protocol To understand our side-channel attacks, we first describe how enables this feature [27] and remote proving services were Zcash guarantees unlinkability. From Section2, recall that designed for early protocol versions [15]. Proof delegation unlinkability relies on two concepts: (1) transactions only is also recommended for hardware wallets [16]. Some contain a commitment to the recipient’s public key, and (2) a users may opt for delegating proofs to a remote service. user can derive multiple unlinkable public keys (diversified • More generally, an adversary may get out-of-band infor- addresses) from a single secret key. mation on when the transaction creation process starts and 4A co-located adversary (which is not part of Zcash’s threat model [18]) observe when it ends by monitoring the P2P network. For can likely recover significantly more information by exploiting more fine- example, a user could setup recurring payments, where grained timing side-channels, e.g., from a shared cache.

2744 29th USENIX Security Symposium USENIX Association Zcash’s diversified addresses are static Diffie-Hellman keys. recover a user’s IP address, link diversified payment addresses, The private key is a scalar, ivk (the incoming viewing key). A and even open a timing side-channel that (in principle) enables diversified public key is of the form (Gd,PKd) where Gd is a remote extraction of the victim’s private viewing key, ivk. random point in an elliptic curve group and PKd = ivk · Gd. Both the PING and REJECT attacks exploit a (weak) form A payment to the address (Gd,PKd) contains a UTXO (a of “decryption oracle” [14,41], that allows the adversary to Note commitment) of the form: learn whether a given ciphertext was correctly decrypted by a node. Yet, our setup is quite different from a standard chosen cm = Commit(Gd||PKd||v;rcm) , ciphertext attack. Indeed, such attacks typically rely on the where v is the sent amount and rcm the commitment random- ability to send arbitrary ciphertexts to a (single) victim, and to ness. To later spend this UTXO, the receiver has to prove that learn some predicate of the decrypted plaintext (e.g., whether she knows an opening of cm. the plaintext is correctly formatted or not [6, 48]). As we will see, in our case the adversary either already knows the Note plaintext (for the REJECT attack) or lacks the ability In-band secret distribution. The sender uses El-Gamal to create new valid authenticated Note ciphertexts (for the encryption to share an opening of cm with the recipient. The PING attack). Instead of trying to break semantic security as sender samples an ephemeral secret key esk, computes the in a traditional CCA attack, our attacks use the decryption public key EPK = esk · G , and derives the shared key d oracle to identify which user, within a network, holds the key

k = esk · PKd = esk · ivk · Gd . to decrypt a transaction’s Note ciphertext. The opening of the commitment cm is included in the Note plaintext (np). The sender encrypts the Note plaintext np Experimental Setup. We evaluate all our attacks on release under an authenticated encryption scheme using the key k, v2.0.7 of Zcash, before the vulnerabilities were fixed in re- and appends the ciphertext C and the ephemeral public key sponse to our disclosure. For experiments in a WAN setting, EPK to the transaction. the victim runs on a machine in Zürich (quad-core Intel i7- 7700 [email protected] with 8GB of RAM running Ubuntu Blockchain scanning. To recover her funds, a user scans 18.04.2) and the remote attacker runs on a Google cloud in- each transaction with her private key ivk. For a transaction stance in London (N1 standard instance). We measure an with public key EPK, Note ciphertext C and Note commitment average round-trip latency of 21 ms, with sub-millisecond cm, she computes: standard-deviation. TrialDecrypt(ivk,EPK,C,cm) 4.2.1 The PING Attack 1: k = ivk · EPK 2: np = Decryptk(C) Our first attack, PING, exploits the tight coupling between 3: if np = ⊥, return ⊥ wallet and P2P components in the Zcash client. More pre- 4: Parse np as np := (Gd,v,rcm,memo) cisely, we exploit the fact that the Zcash client serially pro- 5: PKd = ivk · Gd cesses all incoming P2P messages, including those that con- 6: if cm 6= Commit(Gd||PKd||v;rcm), return ⊥ tain new transactions. As a result, the time taken to process a 7: return np transaction impacts the node’s processing of other messages. That is, if decrypting C succeeds (which means the user is the A remote P2P adversary can thus build a timing side-channel transaction’s payee), the user checks that the Note plaintext that leaks weather a node is the payee of a transaction. np contains a valid opening of the Note commitment cm. The PING attack applies to any transaction, even those sent by honest users and for which the adversary does not know 4.2 Our Attacks the payee’s public key. Our attacks — PING and REJECT — enable an adversary to tell whether a remote Zcash node succeeded in decrypting A timing side-channel in transaction processing. If a the Note ciphertext of a transaction. From this, the adversary Zcash wallet successfully decrypts a Note ciphertext, it checks learns that this remote node belongs to the transaction’s payee. that the opening of the Note commitment is valid (line6 in The two attacks differ in their setup (REJECT only applies TrialDecrypt). This involves computing a Pedersen hash [27] to transactions crafted by the attacker, while PING applies to with two elliptic curve scalar multiplications. A TrialDecrypt any transaction), and in the side-channel they exploit (an error call thus takes longer (by about one millisecond on a desktop message for REJECT, and a timing side-channel for PING). machine) when the decryption succeeds. As described in Section 3.2, identifying the P2P node of a A P2P adversary can measure the duration of the transaction payee further lets an adversary link transactions, TrialDecrypt call by sending a “ping” message to a Zcash

USENIX Association 29th USENIX Security Symposium 2745 node immediately after it receives a new transaction.5 49.5

The node’s wallet first processes the transaction and calls 49.0 TrialDecrypt, before the node responds to the ping. The time elapsed until the receipt of the ping response leaks informa- 48.5 tion about the success of the Note decryption, and therefore 48.0 on whether the node was the payee of the relayed transaction. 47.5

47.0

A timing side-channel in block processing. The above PING response time (ms) attack applies to unconfirmed transactions that enter a victim 46.5 node’s memory pool. The same vulnerability also applies to 46.0 Wallet is Payee Wallet is not Payee the processing of transactions included in a mined block. Upon receiving a new block, a Zcash node sequentially Figure 2: PING attack on unconfirmed Zcash transac- processes and trial-decrypts each transaction in it. The total tions in a WAN. For 200 transactions sent to a node, we time time to validate the block thus depends on the number of the node’s response to a subsequent ping message. When the transactions that pay the user. As above, a remote adversary node’s wallet is the transaction’s payee, the ping response is can leak this validation time by pinging the victim node right delayed. The figure shows standard box plots with outliers. after it receives a fresh block. 114

Applying the attack. The attacker first builds a baseline 112 by running the PING attack against a target node, using a transaction that does not pay the target (the attacker can send 110 funds to itself). The timing of the ping responses from a baseline for a TrialDecrypt call where decryption fails. The 108

attacker then compares this baseline to timings obtained from PING response time (ms) 106 attacks on new transactions. The attack requires reliable measurements of a node’s trans- 104 Wallet is Payee Wallet is not Payee action processing time. Note that for transactions sent by Figure 3: PING attack on mined Zcash transactions in a honest users, the attack cannot be repeated to average out net- WAN. For 20 blocks (each containing a single transaction) work jitter, because, once a node has validated a transaction, it sent to a Zcash node, we time the node’s response to a subse- ignores further messages containing it. One optimization con- quent ping message. When the node’s wallet is the payee of sists in running both above variants of the PING attack, once the transaction in the block, the ping response is delayed. when the transaction enters a node’s mempool and once when it is included in a block (wallets re-process a transaction when it is mined). The attacker thus gets two timing measurements, 4.2.2 The REJECT Attack thereby halving the variance caused by the network. Our second attack, REJECT, exploits a flaw in the handling of certain malformed transactions. It allows an adversary, in Evaluation. We run the attack in a WAN, with a victim possession of a user’s public key, to send a transaction that node in Zürich and an attacker in London (21 ms round trip causes the user’s P2P node to respond with a “reject” message. latency). The attacker sends 200 transactions, half of which The REJECT attack is weaker than PING, in that it only pay the victim. Figure2 plots the victim’s response time applies to transactions sent by the attacker to a known address. to the attacker’s subsequent ping message. The attacker can At the same time, the REJECT attack does not rely on any distinguish between the two scenarios with 100% precision. timing signals and is thus easier to mount and more reliable. We further validate the attack on block processing. The The flaw exploited by the attack is in the parsing of the adversary relays 20 blocks to the victim, each of which con- Note plaintext in TrialDecrypt (line4). The first byte of a tains a single transaction that either pays the victim or another plaintext encodes the protocol version (0x01 in the current user. Figure3 plots the delay of the victim’s ping response. Sapling version). If the version byte is incorrect (i.e., other The attack achieves 100% precision. The attack extends to than 0x01 for Sapling transactions), the parser throws an ex- blocks with N > 1 transactions, by using as baseline the time ception that is caught in the client’s main message-processing to validate a block with N non-paying transactions. thread, where it causes a “reject” message to be sent to the peer that shared the transaction (see Figure4). 5 A ping is a standard protocol message that Zcash P2P nodes send to their This provides a P2P adversary with an oracle indicating the neighboring peers at regular intervals, to confirm that their shared TCP/IP connection is still valid. Upon receiving a ping message, the P2P node replies successful decryption of a Note ciphertext with a specifically with a “pong” message. malformed plaintext (e.g., with a version byte of 0x02).

2746 29th USENIX Security Symposium USENIX Association SaplingNotePlaintext::decrypt in Note.cpp 3000 pt = AttemptSaplingEncDecryption(C, ivk, epk); if (!pt) { return boost::none;// decryption failed 2500 } 2000 CDataStream ss(SER_NETWORK, PROTOCOL_VERSION); ss << pt.get();// serialize the plaintext 1500 SaplingNotePlaintext::SerializationOp in Note.hpp 1000 unsigned char leadingByte = 0x01; Number of Points READWRITE(leadingByte); 500 if (leadingByte != 0x01) { throw std::ios_base::failure(...); 0 } 104 105 106 107 Time [ s] ProcessMessages in main.cpp Figure 5: Time to compute ivk · P for a fixed ivk and one try{ fRet = ProcessMessage(pfrom, strCommand, ...); million random points P in the elliptic-curve group. } catch(const std::ios_base::failure& e) { pfrom->PushMessage("reject", ...); } If an attacker were to get hold of payment addresses for a Figure 4: Error handling exploited by the REJECT attack. large number of Zcash users, this flaw could lead to a strong The code is from Zcash version 2.0.7, before the attack was DoS attack vector. Worse, if an attacker knows the payment patched. Top: if decryption of a Note ciphertext C succeeds, addresses of many Zcash miners, such a DoS attack could be the decrypted stream is serialized into a Note plaintext. Mid- exploited to stifle the network’s mining power (e.g., in prepa- dle: an exception is thrown if the plaintext’s first byte does ration for a 51% attack or to remove mining competition). not encode the protocol version. Bottom: the client’s message- processing thread catches the exception, and sends a “reject” Key recovery via ECDH timing. The PING and REJECT message to the peer that sent the malformed transaction. attacks also yield a remote timing channel on Zcash’s imple- mentation of the ECDH key exchange, in particular the Ellip- tic curve multiplication ivk · EPK in TrialDecrypt (line1). Linking a public key to a node. Given a public key The Zcash team was aware that the ECDH key exchange (G ,PK ) d d , the attacker can identify the Zcash node that holds is not constant time, and that this might be exploitable by a this key. The attacker builds a Note plaintext with an incorrect co-located adversary [18]. The REJECT and PING attacks (G ,PK ) leading byte, encrypts it under a key derived from d d further open up the possibility of this side-channel being ex- and adds it to a transaction. The attacker sends the transaction ploited remotely. to all P2P nodes and checks which one replies with a “reject” Zcash’s Elliptic Curve multiplication routine is indeed not message. We validated this attack in a local test network. constant-time: it uses a standard double-and-add procedure, A potential issue is that a peer that receives the malformed and the underlying field arithmetic is not constant time. We transaction could relay it to the payee before the attacker’s adapted Kocher’s timing attack [29] to Zcash’s Elliptic Curve own message reaches the payee. In this case, the payee will multiplication routine. For a fixed secret ivk, we locally timed send a “reject” message to the relaying peer, and ignore the the multiplication for 1 million random points. The timing attacker’s later message. Yet, as nodes validate transactions distribution is plotted in Figure5, and is clearly not constant. before relaying them, the attacker’s message is likely to reach Assuming we have already recovered the j most significant the payee first. In the event that the attacker does fail to receive bits of ivk, we recover the ( j + 1)-th bit by correlating the a “reject” message, the attack can simply be repeated. time of a point doubling or point multiplication with the total multiplication time. Conditioned on all previous bits being 4.2.3 Attacks beyond Recipient Discovery recovered, the following bit is recovered with 98.4% proba- bility. Using a suitable backtracking mechanism to resolve The vulnerabilities underlying the above attacks can be further the few false guesses, the full key could thus be recovered exploited for adversarial goals beyond linking transactions with about one million samples. and de-anonymizing public keys. The query complexity of this attack is fairly high. The at- tack was performed in an “idealized” setting that ignores the Denial of service. A curious consequence of the REJECT time taken by the network and transaction verification, which attack is that once a transaction containing a malformed Note would add significant noise and further increase the sample plaintext is included in a mined block, the transaction payee’s complexity of a full remote attack. Our proof-of-concept of client crashes when attempting to validate the block. course also confirms the Zcash team’s suspicion that a co- This flaw is pernicious. Even if the Zcash client is manually located adversary could exploit timing side-channels to re- restarted, it re-crashes immediately while validating the block. cover a user’s secret keys.

USENIX Association 29th USENIX Security Symposium 2747 4.3 Remediation 5.1 Unlinkability in Monero We first provide a high-level overview of Monero’s use of Fixing the REJECT attack is simple: treat a plaintext parsing stealth-addresses, a technique for deriving a re-randomized failure as a decryption failure and ignore the offending cipher- public key for every transaction sent to the same recipient, so text. This fix was added in release 2.0.7-3 of Zcash [17, 20]. as to guarantee unlinkability. The PING attack exploits a lack of isolation between a A Monero user, Alice, has a public key of the form Zcash node’s P2P and wallet components. Release 2.0.7-3 addresses this issue by refactoring the wallet into a separate (A,B) = (aG,bG) , thread, that periodically pulls the list of recent transactions and calls TrialDecrypt. The timing of the TrialDecrypt call where G is a base point in an elliptic curve group. The pair 2 thus no longer affects the timing of other P2P functionalities. of scalars (a,b) ∈ Zq is Alice’s secret key. To receive funds Yet, release 2.0.7-3 only fixes the PING attack on unconfirmed from another user, Bob, Alice shares her public key (A,B) transactions. Refactoring the node’s processing of new blocks with Bob. was more complex, and ultimately fixed in release 2.1.1 [22]. When Bob sends a transaction to Alice, he produces a ran- A simple defense against the type of attacks we present is domized public key via a Diffie-Hellman key exchange with to run two Zcash nodes, a “firewall” node that connects to the the first half of Alice’ key (A), which is further mixed with the P2P network and a local node holding the user’s keys that second key half of the key (B). The goal is to produce a point only connects to the firewall. This setup requires storing and P such that only Alice can compute the discrete logarithm of validating the entire blockchain twice, yet prevents all our P with respect to G. R attacks — except for the DoS attack in Section 4.2.3. Concretely, Bob picks an ephemeral secret key r ←− Zq and We note that running a Zcash node over Tor [19] does computes not prevent our attacks. A P2P adversary with an active Tor P = H (rA) · G + B , connection to a victim’s P2P node could still link transactions ∗ where H : {0,1} → Zq is a hash function. The public keys P that pay the victim, or link the victim’s diversified addresses. and R = rG are included in the transaction. Note that P hides Finally, we believe that Zcash should produce a side- Alice’s public key (A,B). channel resistant implementation of their core cryptographic To later spend the received UTXO, Alice needs to prove primitives. Side-channel resistance may have seemed like a knowledge of a scalar x such that P = xG. Given (P,R), she secondary concern, given that the Zcash protocol is primarily can compute this secret as non-interactive. As our attacks have shown, a single bug in the in-band secret distribution routine inadvertently allowed P = H (rA) · G + B = (H (aR) + b) · G . for a two-way interaction between an attacker and victim, | {zx } thereby opening up a potential remote timing side-channel on the Zcash non-interactive key-exchange mechanism. In-band secret distribution. As with Zcash’s in-band se- cret distribution described in Section 4.1, the sender transmits some secret information to the receiver as part of the trans- 5 Attacks on Unlinkability and Anonymity in action. In Monero, the only information the receiver needs is the amount of transacted funds (which is hidden inside a Monero commitment). For this, the sender derives a symmetric key k from the shared secret P and encrypts the transaction amount We now describe side-channel attacks on unlinkability and under k. The ciphertext C is appended to the transaction. user anonymity in Monero. These attacks differ conceptually from those we found in Zcash, as the Monero client separates Blockchain scanning. Upon seeing a transaction with keys the wallet and P2P components into different processes. (P,R) and ciphertext C, a user with private key (a,b) and While such a design is safer in principle, we found that public key (A,B) first computes wallet actions still leak to a remote adversary through network traffic and timing side-channels. First, we describe attacks that x = H (aR) + b infer receipt of a transaction by passively analyzing the traffic P0 = xG , between a wallet and remote node (Strategy 1 in Section 3.2). Second, we show that even if a user’s wallet and node are co- and checks whether P0 = P. If the points match, the user is located, the local wallet-to-node interactions affect the node’s the transaction’s payee. The user further decrypts C using a P2P behavior, which leaks to a remote adversary via a timing symmetric key k derived from P. This extra decryption, and side-channel. This latter attack combines aspects from both some bookkeeping for received funds, is the basis for the of the attack strategies described in Section 3.2. timing side-channel attacks described in Section 5.3.2.

2748 29th USENIX Security Symposium USENIX Association 5.2 Monero Deployments get_hashes get_hashes Before introducing our attacks, we discuss typical deploy- ... H1, H2 ments of the official Monero client. While all common setups Tx1 Process Tx1 are subject to some form of our attacks, some are more vul- get_tx {H1, H2} Tx1, Tx2 nerable than others. Sleep ... get_hashes ... get_hashes Tx2 Process Tx2 Remote nodes. Due to memory and computation re- H1, H2 Sleep quirements of P2P nodes, many users connect their wal- get_tx {H1} get_hashes let to a remote node, possibly hosted by a third-party (e.g., moneroworld.com). By default, Monero wallets connect to a Figure 6: Side-channels in the communication between a third-party node upon creation, until a local node downloads Monero wallet and P2P node. Left: a traffic analysis side- the blockchain (a process that can take several days). channel (Section 5.3.1). The wallet polls its node for new Since a P2P node cannot access the wallet’s keys, using a transaction hashes, and requests transactions Tx1 and Tx2. third-party node is safe in principle. Yet, some privacy risks During its next refresh, the wallet re-requests Tx1, which re- are known (e.g., the node’s host learns the wallet’s IP address veals that it is the payee. Right: a timing side-channel (Sec- and can launch an easily detectable attack to trace the wallet’s tion 5.3.2). Because the wallet is the payee of Tx1, the process- transactions [36]). However, there are no known attacks that ing time for this transaction is increased. The delay before the allow a third-party node to link transactions, nor any known wallet’s next request reveals that it is the payee of Tx1. attacks on wallets that connect to a remote owned node or to a local node. We show examples of such attacks. Experimental Setup. Our experimental setup is similar to the one we used for Zcash. We evaluate all our attacks on Wallet types. The Monero client has three wallet imple- release v0.14.1.0 of Monero, before the vulnerabilities were mentations, whose distinct refresh policies impact our attacks. fixed in response to our disclosure. For experiments in a WAN The main RPC interface — and the GUI wallet built on top setting, the victim runs on a machine in Zürich (quad-core of it — refresh at fixed intervals (every 20 or 10 seconds) Intel i7-7700 [email protected] with 8GB of RAM running to fetch new blocks and unconfirmed transactions from the Ubuntu 18.04.2) and the remote attacker runs on a Google P2P node. The command-line interface (CLI) wallet refreshes cloud instance in London (N1 standard instance). We measure every second, but only fetches new blocks of confirmed trans- an average round-trip latency of 21 ms, with sub-millisecond actions. While all wallet types are vulnerable, the CLI wallet standard-deviation. is susceptible to different attacks. We focus here on the RPC and GUI wallets, and discuss the CLI wallet in AppendixA. 5.3.1 Traffic Analysis Attacks for Remote Nodes We first describe attacks that exploit the communication pat- 5.3 Our Attacks terns between a wallet and remote node. Upon an automatic refresh, the wallet first requests the list of unconfirmed trans- Our attacks exploit differences in the interactions between actions from the node, and receives a list of hashes. It then a wallet and node, when the wallet is the payee of a new requests the bodies for two types of transactions: (1) those unconfirmed or mined transaction. that the wallet has not processed before; and (2) previously If the wallet connects to a remote node, a network adversary seen transactions of which the wallet is the payee. (or a malicious remote node) can infer receipt of a payment by A malicious remote node thus trivially learns which trans- passively monitoring the encrypted traffic between the wallet actions pay the wallet, by reading the wallet’s requests. Even and remote node (see Section 5.3.1 and Section 5.3.2). if the remote node is trusted, a passive network adversary can Moreover, even if a user’s P2P node and wallet are co- detect the wallet’s transaction request (the communication located, we show that a P2P adversary can still exploit side- between wallet and node is easy to fingerprint, as the wallet channels to infer when the wallet receives a payment. We refreshes at fixed intervals). The mere presence of this request show an active attack that sends requests to a victim’s P2P can leak that the wallet was the payee of a transaction. With node and times the responses, in order to reveal lock con- Monero’s traffic in May 2020 (10,000 transactions per day, tention over the victim P2P node’s resources that indicates or one every 9 seconds on average) it is common that no new the receipt of a payment (see Section 5.3.3). transaction enters the mempool between two wallet refreshes. As in Zcash, these attacks further enable linking a known If the wallet issues a transaction request even though the mem- public key to the IP address of the owner’s P2P node or wallet, pool has not changed, the request must be for a previously as well as linking of a user’s diversified addresses. seen unconfirmed transaction that pays the wallet.

USENIX Association 29th USENIX Security Symposium 2749 The attack extends to blocks with N > 1 transactions. The

8 adversary first estimates the time taken to process N trans- actions that do not pay a wallet, and compares this estimate

7 to the observed delay. Even though the time to process non- paying transactions varies slightly from one transaction to 6 another, this variation is negligible compared to the multi- millisecond delay incurred when processing a payment. 5 5.3.3 Timing Attacks for Local Nodes 4 Time between RPC requests (ms) The attacks from Section 5.3.1 and Section 5.3.2 require Wallet is Payee Wallet is not Payee that the victim’s wallet connects to a remote node. We now Figure 7: Timing of block requests in Monero. Plots the describe a more complex attack that applies even to a co- delay between block requests from a wallet to a remote node, located wallet and node. when the first block has one transaction for the wallet (left), or In this case, a remote adversary cannot observe communi- for another user (right). The experiment is repeated 20 times. cation patterns between the victim’s node and wallet. Yet, we develop an attack that lets a P2P adversary infer these commu- nication patterns. Specifically, we show that an attacker can We validated the attack in a local Monero network, but note detect when a remote wallet issues a transaction request to its that the attack succeeds with 100% accuracy regardless of node. As we described in Sections 5.3.1 and 5.3.2, the pres- the network type, because it relies only on the presence or ence of this request (or the time between two requests) leaks absence of transaction messages and not timing signals. that the wallet is the payee of an unconfirmed transaction. Our attack exploits overly-coarse locking in Monero’s P2P 5.3.2 Timing Attacks for Remote Nodes nodes. When processing a transaction request — sent either by a wallet or by a peer via a get_objects message — the In addition to the number of network requests exchanged P2P node acquires a global lock on its mempool. Thus, if a between a wallet and node, we now show that the time elapsed P2P adversary sends a get_objects message right after a between requests also leaks whether a wallet was paid. request from the victim wallet, lock contention in the P2P For each new transaction, the wallet checks if it is the trans- node will delay the response to the attacker. The chances of action’s payee. If so, it further decrypts the obtained value lock contention are high as the P2P node validates requested (see Section 5.1 for more details). As a result, processing a transactions before releasing the lock, which results in the transaction takes more time if the wallet is the payee of that lock being held for tens of milliseconds upon a wallet request. transaction (the delay on a desktop machine is about 2-3 ms). To reduce the risk of the attacker’s request locking out the wal- This difference in processing time leads to two timing let’s request, the attacker only sends requests for non-existing attacks. The first targets the processing of new blocks. Upon transactions so that the lock duration is small. Observing the a refresh, the wallet serially downloads a new block from size of the response delay indicates to the attacker whether the node and processes its transactions. The time between the wallet has issued a transaction request to its node, or not. two block requests thus leaks the processing time of the first In turn this tells the attacker if a particular transaction is a block’s transactions. The second attack targets unconfirmed payment to the target wallet or not. transactions. Recall that the wallet refreshes at fixed intervals (e.g., every 20 seconds for the RPC wallet). More precisely, Evaluation. The timing difference induced by the lock con- the wallet sleeps for a fixed amount of time at the end of a tention depends on the current size of the node’s memory pool. refresh. Thus, the time at which the wallet wakes and sends With 20 transactions in the mempool, the lock is acquired for a new request depends on the time it took to process the about 15-20 ms upon a request from the wallet. transactions received in the previous refresh. We ran the attack in a WAN, with the victim’s wallet and node co-located in Zürich, and an attacker in London. The memory pool contains 20 transactions one of which pays the Evaluation. Figure7 plots the delay between block re- wallet.6 Every 10 seconds, the wallet refreshes and sends a quests made by a user’s wallet when the first received block transaction request (as there is a payment for the wallet in the contains a single transaction. If the wallet is the transaction’s payee, the next block request is delayed by 3.4 ms on aver- 6According to https://moneroblocks.info, during May 2020, Mon- age. A similar delay is observed between two wallet refresh ero’s blocks contained over 18 transactions on average, with about 35% of periods when the wallet processes a transaction of which it blocks containing at least 20 transactions. Thus, the memory pool contained at least 20 transactions when those blocks were mined. Note that an adversary is the payee. These timing differences are large enough to be can artificially increase the mempool size by sending dummy transactions reliably observable in a WAN setting. with the minimum transaction fee.

2750 29th USENIX Security Symposium USENIX Association This issue is pernicious. Zcash’s recently released mobile Wallet transaction request SDKs [21] have the same flaw: the mobile wallet repeatedly: 40 Delay of get_objects response (1) requests new transactions from a remote node; (2) pro- cesses these transactions; and (3) sleeps for a fixed duration. 35 An incomplete fix, which was originally proposed by both Monero and Zcash, randomizes the sleep duration after a 30 Delay [ms] refresh. This fix may suffice against an adversary that targets a transaction sent by an honest user, and is thus limited to a 25 single timing measurement. However, randomized delays are insufficient against an adversary that targets a known public 20 0 10 20 30 40 50 60 key. In this case, the adversary can create multiple payments Time [s] for this public key, and time the duration between refreshes Figure 8: Remote lock timing attack on Monero. Plots the of a target wallet for each transaction. If the wallet holds the response time of a victim’s local P2P node to get_objects public key, the average refresh time will be larger. requests from a P2P adversary in a WAN. The attacker sends A better fix consists in fully decoupling the starting times 2365 requests in one minute. The dotted red lines indicate and processing times of wallet refreshes. A simple approach when the victim’s wallet issued a request for a transaction of is to have the wallet wake at fixed time intervals (e.g., at the which it is the payee. The wallet’s requests cause lock con- start of every minute). Since an adversary can tell when a tention which delays the P2P node’s response to the attacker. refresh period starts but not when it ends, this prevents our attacks. Both Zcash and Monero implemented this solution. Our attacks on Monero’s CLI wallet (see AppendixA) have mempool). The attacker continuously sends get_objects 7 only been partially addressed as the current fix uses a variant messages to the victim’s node and times the response. Our of the above incomplete randomization defense. experimental results are shown in Figure8. The correlation between timing delay and wallet requests is abundantly clear. As described, the attack assumes that the mempool is un- 6 Timing Attacks on zkSNARK Provers changed for at least two wallet refreshes (i.e., for 20-40 sec- onds) after the payment to the wallet enters the pool. Since The side-channel attacks we described in Section4 and Sec- Monero has about one transaction every 17 seconds and a new tion5 circumvent unlinkability and anonymity guarantees block every 2 minutes, such periods of inactivity are common. by exploiting flaws in the system design of P2P clients and wallets. In this section, we further investigate the potential for side-channel vulnerabilities in one of the fundamental 5.4 Remediation cryptographic primitives used in these systems: succinct zero- Our attacks were fixed in Monero’s v.0.15.0 release. The wal- knowledge arguments (zkSNARKs). let now only requests unseen transactions from its P2P node, Following the strategy outlined in Section 3.3, we aim to thus preventing the attacks in Section 5.3.1 and Section 5.3.3. recover information about the confidential transaction amount, The wallet also requests and processes new blocks in batches from a single timing measurement of the proof generation. In of 1,000 blocks. Thus, the timing attack on block processing Section 6.1, we demonstrate that such timing attacks reveal from Section 5.3.2 can at best infer that a wallet was paid by information about transaction amounts in Zcash. In contrast, some transaction in a batch. A stronger defense would be to we show in Section 6.2 that similar attacks are ineffective for issue block requests on a fixed schedule, as described below. the special-purpose proofs implemented in Monero.

Decoupling refresh time from processing time. The tim- 6.1 Timing Side-Channels in the Zcash ing attack on the processing of unconfirmed transactions in Prover Section 5.3.2 is due to a design flaw that has the wallet sleep for a fixed amount of time after a refresh. The start time of a We show that for Zcash’s zkSNARK system, proving times refresh thus leaks the duration of the previous refresh period, heavily depend on the value of the prover’s witness. In partic- which itself reveals if a payment was processed. ular, for anonymous transactions, we show that proving times are heavily correlated with a transaction’s confidential value. 7A technical issue is that the attacker cannot send get_objects requests To send a transaction, the sender creates two proofs, one at too high of a rate, as this causes the victim’s TCP congestion control that proves ownership of the spent UTXOs, and one that mechanism to delay the sending of some responses, thereby adding significant proves that new UTXOs are well-formed. In both proofs, noise to the timing measurements. Specifically, the attacker waits for one round-trip time between each request it sends, so as to leave sufficient time the witness is a vector that contains, among other terms, a for the victim’s response message to receive an ACK. binary decomposition of the transacted value.

USENIX Association 29th USENIX Security Symposium 2751 with zero value. An adversary capable of timing a prover 5.380 could thus re-identify dummy UTXOs with good accuracy.

5.375 Discussion Compared to the attacks described in Section4

5.370 and Section5, the above timing attack is not easy to apply. It requires that an adversary can time a proof generation, an

Proof Time [s] 5.365 R = 0.57 assumption that depends on users’ common usage patterns (e.g., recurring payments) or deployment strategies (e.g. out- 5.360 sourcing proofs to a remote service). If a timing opportunity

0 210 220 230 240 250 260 does exist, we show that the resulting leakage allows for a Value in ZEC coarse approximation of the private transaction amount. Figure 9: Correlation between transaction amount and Of course, local side-channel attacks would be much more prover time in Zcash. For each of 200 random values, we effective. Yet, Zcash explicitly discounts this threat and makes plot the mean and standard deviation in proof time for 20 no claims of security against a co-located adversary [18]. transactions of that amount. The correlation coefficient be- Ultimately, this attack serves as a warning about potential tween the value (in log-scale) and proof time is R = 0.57. future dangers arising from non-constant-time cryptographic implementations. A more mature implementation of Zcash’s elliptic curve arithmetic is in development [7] and likely to Zcash uses the Groth16 proof system [25]. For our pur- be incorporated into the main client in the future. We note poses, it suffices to know that the prover encodes the witness that the use of constant-time cryptography need not introduce as a vector (a1,...,am) of field elements, and that the prover’s a large computation overhead. In Figure9 for example, we main computation is a “multi-exponentiation” of the form: observe that the best-case and worst-case prover times differ by less than 20 milliseconds, which is less than 1% of the m total prover time. Thus, even if all proofs were to take the ∑ aiGi , (1) i=1 constant worst-case time, the overhead would remain small. where the Gi are fixed elliptic curve points. Importantly, Zcash’s implementation optimizes away terms aiGi where 6.2 Absence of Timing Side-Channels in the ai = 0. The proof time thus correlates with the number of Monero Prover non-zero field elements in the prover’s witness. In contrast to Zcash, Monero does not make use of a general- Since the transaction amount is encoded in binary in the purpose zk-SNARK system. Instead, the spender of a Monero witness, its Hamming weight influences the proving time. And transaction only proves that the confidential transaction con- since the weight of a number’s binary representation is cor- tains a commitment to a value that is in the range [0,264). related with the number’s absolute value, the proof duration This “range proof” is based on Bulletproofs [10]. leaks information about confidential transaction amounts. At a first glance, we may expect Monero’s proofs to ex- hibit a similar timing side-channel as in Zcash. Indeed, Mon- Evaluation. To evaluate the timing attack, we picked 200 ero’s range proof also performs a multi-exponentiation over t transaction amounts of the form 2 for t uniformly random in a binary decomposition of the transaction value, similarly [0,64). Note that the proof witness contains other ephemeral to equation1. However, a crucial difference is that Bullet- terms besides the amount (e.g., commitment openings), which proofs operate not only on the binary decomposition of a also contribute to the variability in proving time. For each of value but also on its bit-wise complement. More specifically, the 200 random amounts, we thus create 20 transactions by given a transaction amount v ∈ [0,2n), the prover computes randomizing over all other ephemeral witness components. n the vector aL ∈ {0,1} as the binary decomposition of v, and We then time the prover for each of these 4,000 transactions. n n sets aR = aL − 1 ∈ {−1,0} . The prover then computes a Figure9 shows the mean and standard deviation of proving Pedersen commitment of the form times for each amount. Proving time and transaction amount are strongly correlated (R = 0.57). While the timing leaks n (a ) · G + (a ) · H , only a coarse approximation of the amount, this could suffice ∑ L i i R i i i=1 to confidently identify rare transactions of large value. The left-most proof timings in Figure9 correspond to trans- where the Gi and Hi are fixed base points in an elliptic curve action amounts of zero. Fingerprinting such proofs is partic- group. All further prover operations are on randomized values ularly interesting due to Zcash’s “dummy Notes” (see [27]): independent of v. As a result, the number of computed elliptic to obfuscate the number of UTXOs in a transaction (e.g., to curve operations is a constant independent of the transaction resist the attacks from [4]), users can create dummy UTXOs amount v. We note that this property is inherent to the proof

2752 29th USENIX Security Symposium USENIX Association 40] and Monero [30, 37]. These attacks exploit protocol-level 21.3 R = 0.04 leakage and are agnostic to the protocol’s system-level im- 21.2 plementation. As a consequence, these attacks are ineffective against transactions with particularly strong cryptographic 21.1 anonymity guarantees, such as Zcash’s fully shielded trans-

21.0 actions. In contrast, our side-channel attacks exploit imple- mentation flaws and bypass these cryptographic protections Proof Time [ms] 20.9 to link or break confidentiality of arbitrary transactions.

20.8 Closest to our work are early attacks on Bitcoin by Lerner [31]. These attacks — which are similar in spirit to 0 210 220 230 240 250 260 Value in pico-monero our attacks on Zcash — let an attacker link a Bitcoin address to the IP address of the owner’s P2P node. Figure 10: Correlation between transaction amount and prover time in Monero. For each of 200 random values, Our attacks further relate to the larger study of remote side- we plot the mean and standard deviation in proof time for channels in anonymization tools such as Tor [3, 26, 38, 39] or 20 transactions of that amount. The correlation coefficient mix-networks [32, 46]. between the value (in log-scale) and proof time is R = 0.04. Our remote timing attacks on zk-SNARKs extend the rich literature on similar attacks for other cryptographic primitives or protocols [1,9,29]. Dall et al. [13] proposed a cache-timing protocol described by Bünz et al. [10] and was not included attack on a special-purpose zero-knowledge proof used for as an explicit countermeasure against side-channel attacks. anonymous attestation in Intel SGX. The challenges for tim- Similarly to our Zcash experiment in Section 6.1, for a ing of provers in anonymous transactions (see Section 3.3) do range of random transaction values, we timed 20 proofs with not apply in this setting: the adversary can trigger arbitrarily other witness elements chosen at random (in Monero’s case, many attestations in a co-located enclave and perform high- the witness consists of the transaction amount and a random precision local cache-timing measurements of the prover. blinding vector). Figure 10 shows that proof times are es- sentially independent of the transaction amount (the slight correlation can be attributed to measurement noise). Never- 8 Conclusion theless, we do observe that proof times are not constant, with variations of up to 0.5 milliseconds between proof times. This We have presented a number of remote side-channel attacks can be attributed to the fact that Monero’s implementation of on anonymous transaction systems such as Zcash and Monero. the elliptic curve multi-exponentiation is not constant-time, We have shown powerful attacks on transaction unlinkability with some data-dependent operations and memory-access pat- and user anonymity that exploit timing side-channels and terns. However, the small resulting timing differences seem communication patterns leaked by a user’s P2P node upon insufficient to reliably extract secret information from a sin- receipt of a payment. We have demonstrated that a remote gle remote timing measurement. Of course, performing local adversary can use this leakage to identify the P2P node used attacks would be a much simpler matter. by the secret payee of any transaction, and bootstrap this ability to break user anonymity, transaction unlinkability, and 7 Related Work diversified address unlinkability. We have further studied the impact of timing side-channels Several protocol-level issues with the privacy of anonymous on the zero-knowledge proof systems used in these currencies. transactions were previously studied. In Monero, biases in We have shown that Zcash’s implementation leaks secret the choice of anonymity set were shown to enable transaction transaction data through the timing of a proof generation. tracing [37]. In Zcash, the low volume of anonymous transac- In principle, an attacker that can time a proof generation can tions was shown to enable tracing of many transactions via exploit this leakage to extract information about the transacted usage pattern heuristics [4,28]. These works suggest protocol- amount, thereby breaking transaction confidentiality. level issues with these schemes, which is very different to the Our attacks reveal a new facet of the difficulty of designing side-channel information leakage studied in this paper. secure systems for anonymous transactions. We hope that Our side-channel attacks complement a large body of work this work will help inform privacy-oriented crypto-currencies on de-anonymization of crypto-currency transactions. Many about the dangers of side-channel leakage. In particular, our authors have shown that analyzing Bitcoin’s public transac- results motivate the need for system designs that proactively tion graph breaks users’ pseudonymity [2,24,34,42,44]. In isolate user wallets from public P2P interfaces, as well as for privacy-focused currencies, common usage patterns can be the development of constant-time implementations of crypto- exploited to link and trace certain transactions in Zcash [4,28, graphic primitives such as zkSNARK provers.

USENIX Association 29th USENIX Security Symposium 2753 Acknowledgments [10] Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. Bulletproofs: We thank the Zcash and Monero security teams for their pro- Short proofs for confidential transactions and more. In fessional handling of the vulnerability disclosure process, for 2018 IEEE Symposium on Security and Privacy (SP), insightful discussions, and for the prompt deployment of re- pages 315–334. IEEE, 2018. mediations. Dan Boneh’s research was supported in part by NSF, ONR, [11] Chainalysis. https://www.chainalysis.com/. the Simons Foundation and a Google faculty fellowship. Ken- [12] Ciphertrace. https://www.ciphertrace.com/. neth G. Paterson’s research was supported in part by a gift from VMware. [13] Fergus Dall, Gabrielle De Micheli, Thomas Eisenbarth, Daniel Genkin, Nadia Heninger, Ahmad Moghimi, and References Yuval Yarom. Cachequote: Efficiently recovering long- term secrets of SGX EPID via cache attacks. IACR [1] Nadhem J Al Fardan and Kenneth G Paterson. Lucky Transactions on Cryptographic Hardware and Embed- thirteen: Breaking the TLS and DTLS record proto- ded Systems, pages 171–191, 2018. cols. In 2013 IEEE Symposium on Security and Privacy, [14] Danny Dolev, Cynthia Dwork, and Moni Naor. Non- pages 526–540. IEEE, 2013. malleable cryptography. SIAM review, 45(4):727–784, [2] Elli Androulaki, Ghassan Karame, Marc Roeschlin, To- 2003. bias Scherer, and Srdjan Capkun. Evaluating user pri- [15] Electric Coin Company. Zcash pull request #2120: Ex- vacy in Bitcoin. In International Conference on Fi- perimental feature: remote proving service. https: nancial Cryptography and Data Security, pages 34–51. //github.com/zcash/zcash/pull/2120, 2017. Springer, 2013. [16] Electric Coin Company. [ZIP 305] best practices [3] Daniel Arp, Fabian Yamaguchi, and Konrad Rieck. Tor- for hardware wallets supporting Sapling. https:// ben: A practical side-channel attack for deanonymizing github.com/zcash/zcash/issues/3038, 2018. Tor communication. In Proceedings of the 10th ACM Symposium on Information, Computer and Communica- [17] Electric Coin Company. Security announcement tions Security, pages 597–602. ACM, 2015. 2019-09-24. https://z.cash/support/security/ announcements/security-announcement-2019- [4] Alex Biryukov, Daniel Feher, and Giuseppe Vitto. Pri- 09-24/, 2019. vacy aspects and subliminal channels in Zcash. In ACM SIGSAC Conference on Computer and Communications [18] Electric Coin Company. Zcash documentation— Security, 2019. security warnings—side-channel attacks. https: //zcash.readthedocs.io/en/latest/rtd_pages/ [5] Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran security_warnings.html#side-channel-attacks, Tromer. From extractable collision resistance to succinct 2019. Revision fe830a5a. non-interactive arguments of knowledge, and back again. In Innovations in Theoretical Computer Science, pages [19] Electric Coin Company. Zcash documentation—Tor 326–349, 2012. support in Zcash. https://zcash.readthedocs.io/ en/latest/rtd_pages/tor.html, 2019. Revision [6] Daniel Bleichenbacher. Chosen ciphertext attacks fe830a5a. against protocols based on the rsa encryption standard pkcs# 1. In Annual International Cryptology Confer- [20] Electric Coin Company. Zcash release v2.0.7- ence, pages 1–12. Springer, 1998. 3. https://github.com/zcash/zcash/releases/ tag/v2.0.7-3, 2019. [7] Sean Bowe. Rust crate bls12_381 v0.1.0. https:// github.com/zkcrypto/bls12_381, 2019. [21] Electric Coin Company. ECC releases resources for building mobile, shielded-Zcash wallets. [8] Billy Bob Brumley and Nicola Tuveri. Remote timing https://electriccoin.co/blog/ecc-releases- attacks are still practical. In European Symposium on Re- resources-for-building-mobile-shielded- search in Computer Security, pages 355–371. Springer, zcash-wallets/, 2020. 2011. [22] Electric Coin Company. Zcash release v2.1.1. https: [9] David Brumley and Dan Boneh. Remote timing attacks //github.com/zcash/zcash/releases/tag/v2.1.1, are practical. Computer Networks, 48(5):701–716, 2005. 2020.

2754 29th USENIX Security Symposium USENIX Association [23] Elliptic forensics software. https:// 2013 conference on Internet measurement conference, www.elliptic.co. pages 127–140. ACM, 2013.

[24] Michael Fleder, Michael S Kester, and Sudeep Pillai. [35] Monero. Monero Pull Request #6074: Fix info leak Bitcoin transaction graph analysis. arXiv preprint when using a remote daemon. https://github.com/ arXiv:1502.01657, 2015. monero-project/monero/pull/6074, 2019.

[25] Jens Groth. On the size of pairing-based non-interactive [36] Monero-Hax123. Corrupt RPC responses from remote arguments. In Annual International Conference on the daemon nodes can lead to transaction tracing. https: Theory and Applications of Cryptographic Techniques, //hackerone.com/reports/304770, 2018. pages 305–326. Springer, 2016. [37] Malte Möser, Kyle Soska, Ethan Heilman, Kevin Lee, [26] Dominik Herrmann, Rolf Wendolsky, and Hannes Fed- Henry Heffan, Shashvat Srivastava, Kyle Hogan, Ja- errath. Website fingerprinting: attacking popular pri- son Hennessey, Andrew Miller, Arvind Narayanan, and vacy enhancing technologies with the multinomial naïve- Nicolas Christin. An empirical analysis of traceabil- Bayes classifier. In Proceedings of the 2009 ACM work- ity in the Monero blockchain. Proceedings on Privacy shop on Cloud computing security, pages 31–42. ACM, Enhancing Technologies, 2018(3):143–163, 2018. 2009. [38] Steven J Murdoch and George Danezis. Low-cost traffic [27] Daira Hopwood, Sean Bowe, Taylor Hornby, and analysis of Tor. In 2005 IEEE Symposium on Security Nathan Wilcox. Zcash protocol specification. Tech- and Privacy (S&P’05), pages 183–195. IEEE, 2005. nical report, Electric Coin Company, 2019. Ver- [39] Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and https://github com/zcash/zips/ sion 2019.0.1 . Thomas Engel. Website fingerprinting in onion routing blob/d39ed0/protocol/protocol pdf . . based anonymization networks. In Proceedings of the [28] George Kappos, Haaroon Yousaf, Mary Maller, and 10th annual ACM workshop on Privacy in the electronic Sarah Meiklejohn. An empirical analysis of anonymity society, pages 103–114. ACM, 2011. in Zcash. In 27th USENIX Security Symposium, pages [40] Jeffrey Quesnelle. On the linkability of Zcash transac- 463–477, 2018. tions. arXiv preprint arXiv:1712.01210, 2017. [29] Paul C Kocher. Timing attacks on implementations [41] Charles Rackoff and Daniel R Simon. Non-interactive of Diffie-Hellman, RSA, DSS, and other systems. In zero-knowledge proof of knowledge and chosen cipher- Annual International Cryptology Conference, pages 104– text attack. In Annual International Cryptology Confer- 113. Springer, 1996. ence, pages 433–444. Springer, 1991. [30] Amrit Kumar, Clément Fischer, Shruti Tople, and Pra- [42] Fergal Reid and Martin Harrigan. An analysis of teek Saxena. A traceability analysis of Monero’s anonymity in the Bitcoin system. In Security and pri- blockchain. In European Symposium on Research in vacy in social networks, pages 197–223. Springer, 2013. Computer Security, pages 153–173. Springer, 2017. [43] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to [31] Sergio Lerner. About my new Bitcoin vulnerability: get leak a secret. In Advances in Cryptology - ASIACRYPT, your peer public addresses. https://bitslog.com/ pages 552–565, 2001. 2013/01/23/new-bitcoin-vulnerability-get- your-peer-public-addresses/, 2013. [44] Dorit Ron and Adi Shamir. Quantitative analysis of the full Bitcoin transaction graph. In International Con- [32] Brian N Levine, Michael K Reiter, Chenxi Wang, and ference on Financial Cryptography and Data Security, Matthew Wright. Timing attacks in low-latency mix sys- pages 6–24. Springer, 2013. tems. In International Conference on Financial Cryp- tography, pages 251–265. Springer, 2004. [45] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars [33] Greg Maxwell. Confidential transac- Virza. Zerocash: Decentralized anonymous payments tions. https://people.xiph.org/~greg/ from Bitcoin. In 2014 IEEE Symposium on Security and confidential_values.txt, 2016. Privacy, pages 459–474. IEEE, 2014. [34] Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kir- [46] Vitaly Shmatikov and Ming-Hsiu Wang. Timing analy- ill Levchenko, Damon McCoy, Geoffrey M Voelker, and sis in low-latency mix networks: Attacks and defenses. Stefan Savage. A fistful of Bitcoins: characterizing pay- In European Symposium on Research in Computer Se- ments among men with no names. In Proceedings of the curity, pages 18–33. Springer, 2006.

USENIX Association 29th USENIX Security Symposium 2755 [47] Nicolas Van Saberhagen. Cryptonote v2.0, 2013. The attacks described in Section5 do not directly apply to the CLI wallet. The CLI wallet only refreshes its copy of the [48] Serge Vaudenay. Security flaws induced by CBC memory pool of unconfirmed transactions on an explicit user padding—applications to SSL, IPSEC, WTLS... In In- prompt, so the attacks from Section5 that target unconfirmed ternational Conference on the Theory and Applications transactions do not apply. Instead, the wallet is vulnerable to of Cryptographic Techniques, pages 534–545. Springer, a much more pernicious timing attack on block processing, 2002. in a setting where the wallet connects to a remote node. Indeed, recall that the CLI wallet requires a user password A Side-Channel Attacks on the Monero CLI in order to obtain the user’s spending key. When processing Wallet new blocks, if the wallet detects that it is the payee of a trans- action (using the tracking key), it displays a password prompt The command-line interface (CLI) for the Monero wallet has to the user and interrupts any further refreshes until the user a slightly different behavior than the RPC and GUI versions responds. This is trivially observable by a remote node or by analyzed in Section5. As a result, the side-channel attacks a network adversary as this interrupts the flow of requests for that apply to the CLI wallet are also different. new blocks, potentially for several seconds, minutes or hours The CLI wallet makes use of a Monero privacy feature depending on the user’s activity. known as a tracking key. Note that in the description of blockchain scanning in Section 5.1, a user only needs “half” This attack vector has only been partially fixed. As of re- of her secret key (the scalar a) to check whether she is the lease v0.15.0, the CLI wallet refreshes at randomized intervals, recipient of a transaction. To compute the secret value x re- to obfuscate delays between refreshes caused by an unan- quired to later spend the received funds further involves the swered password prompt. Yet, as noted in Section 5.4, such use of the second half of the key, the scalar b. The CLI wallet a randomized defense approach is likely insufficient against only keeps the “tracking key” a in memory, to determine when a determined adversary that aims to identify the owner of a the user has received transactions. At that point, it prompts specific public key. Such an attacker can send multiple trans- the user for a password to decrypt the “spending key” b. This actions to this key, and obtain multiple timing measurements behavior differs from the RPC and GUI wallets that hold both that would average out the variability caused by the random- keys in memory (or in a hardware wallet). ized delays between refreshes.

2756 29th USENIX Security Symposium USENIX Association