search

zcash / lightwalletd

Lightwalletd is a backend service that provides a bandwidth-efficient interface to the Zcash blockchain
MIT License
83 stars 86 forks source link

Lightwalletd should not be able to conceal Sapling transactions from wallet app #316

Open holmesworcester opened 3 years ago

holmesworcester commented 3 years ago

Right now, according to the wallet app threat model a malicious or compromised lightwalletd can omit transactions, concealing them from the wallet user.

This is undesirable because it means that a wallet app provides significantly less guarantees to the user than a full node, and it increases how much trust the wallet app user must put in their choice of lightwalletd, increasing centralization.

In Zbay's use case, where memos on Sapling transactions are used to register usernames, it means that a malicious lightwalletd could spoof usernames, and potentially send or receive messages or funds on behalf of a user. https://github.com/ZbayApp/zbay/issues/517

In the light wallet working group, str4d explained that addressing this vulnerability is possible for Sapling transactions, but requires implementing FlyClient support:

It is possible to verify that lightwalletd is not omitting transactions containing Sapling outputs. Light clients can check that the root of the Sapling commitment tree they are building locally matches the hashFinalSaplingRoot field in:

  • Before Heartwood, the block header (now renamed to hashLightClientRoot).
  • After Heartwood, the FlyClient history tree leaf for that block. Light clients would then use a FlyClient proof to confirm that the history tree leaf is correctly part of the chain via the hashLightClientRoot. This requires implementing FlyClient support in light clients and lightwalletd, which has not yet been done.

As I understand this, the fix for this pre-Heartwood can be addressed without changes to lightwalletd, but post-Heartwood the fix requires changes to lightwalletd.

I don't know how much work this is, or how to prioritize it, but it seemed best to create this issue to track it. It seems helpful to address this, in order to bring the security guarantees of lightwallet apps closer to the security guarantees of a full zcash node.

holmesworcester commented 3 years ago

Corresponding zecwalletlight-cli issue: https://github.com/adityapk00/zecwallet-light-cli/issues/62

geffenz commented 2 years ago

This would require changes to lightwalletd and tests. A large onus is on the wallet for requesting and verifying data.

This is on hold until NU5 release and lightwalletd overhaul.