Practical Privacy Issues in Lite Clients

After finding the MITM certificate vulnerability in a lite client last week, I finally got around to looking at the actual lite wallet protocol implementation today, and there is one high level concern that I think can be addressed but it requires some consideration, and discussion before any implementation should be attempted.

The primary problem is that, practically, the anonymity set for fetching interesting transactions (i.e. to get the memo) is too small, Many blocks only contain a handful of transactions and, regularly, only 1 or 2 shielded transactions. This means that the server can link a small set of transactions to a client. Given prior research which has shown linking of shielded transactions based on usage, it seems clear that the current strategy of per-client random transactions fetches to mask the target transaction isn’t robust.

Part of this issue is caused by the lite client implementations not using an anonymizing network to communicate with the server as assumed by the original spec. And effort might be better directed by moving in that direction which would reducing the ability of a rogue server to link requests.

Widening the threat model however, I think moving towards a mechanism where all lite wallet clients download all transactions in blocks containing smaller numbers of transactions (for the sake of argument, let’s call it <= 3), regardless of interest, should go some way to mitigating this with minimal bandwidth costs and increase the practical anonymity set.

The above definitely needs more formal treatment before being implemented, so I thought I would open a discussion.

(Crossposted from https://github.com/adityapk00/zecwallet-lite/issues/43 at request of @adityapk00 to facilitate a wider discussion)

13 Likes

Could Walking Onions fill the anonymity net?

Walking Onions will definitely help make Tor a more attractive option for mobile applications by minimizing bandwidth use associated with the tor consensus, with that scalability improvement on the horizon it makes sense, in my opinion, to expose lite wallet servers as tor onion services - which would go a long way to improving the privacy properties in practice.

5 Likes

As I understand the problem, this would only solve a part of the problem with privacy as it relates to lite clients. Have you given any thoughts to how one might preserve the privacy of receivers in this case?

Most of these are thoughts on preserving the privacy of receivers as they are the ones who are directly fetching transactions from the lite servers and remain most at risk of both linking individual transactions to a known identifier (like an IP address) and also in linking sets of transactions together (by e.g. fetching two isolate transactions from two separate blocks via the same connection). Receivers are why I proposed that all lite client download all transactions in small blocks - to maximize the practical anonymity set.

3 Likes

Widening the threat model however, I think moving towards a mechanism where all lite wallet clients download all transactions in blocks containing smaller numbers of transactions (for the sake of argument, let’s call it <= 3)

Found some time this morning to gather some data on this. In the last 60 days, ~27% of blocks contained just 1 transaction. Another ~20% contained 2 transactions and an additional 14% contained 3.

Screenshot_20200313_135656

This means that requiring a lite client to download all transactions in blocks with small numbers of transactions results in a requirement to download 7% / 17% / 28% of all transactions depending on the transaction count parameter (i.e. all transactions in blocks with only a single transaction, or with up to 2 or with less than 3 respectively)

The question then become, does requiring all lite clients to download all transactions in blocks with just a single transaction (27% of blocks, 7% of all transactions) impose a bandwidth requirement that is insurmountable for lite clients?

Rough math, assuming 2.5kb per transaction and ~576 blocks per day, with 27% of them only containing a single transaction, gives a rough estimate of +400kb per day. Extending this up to blocks containing 3 or fewer transactions doubles this to +800kb per day per client.

That seems fairly low bandwidth usage for providing all lite clients with a much more robust anonymity set - especially considering the alternative, which is that lite clients have a 1/4 chance of having their transactions trivially linkable if they are not behind a proxy (practically probably much higher depending on the number of lite clients and the external information available to an adversary).

Is there anything I’ve missed?

5 Likes