A malicious lightwalletd could spoof user accounts by "censoring" a username registration message

[holmesworcester]

According to the Zcash wallet app threat model a malicious lightwallet server can hide certain transactions from the user.

Our user registration system, however, assumes that all username registrations will be available to everyone. This is true in a fully synced full node, but not true in the lightwallet context.

Proposal:

We should provide an API for username registration.

• This API should tell users when a username has been registered.
• This API should collect the necessary information from the user, and send username registration messages to the username channel on the user's behalf.
• The API should be based on a full node so it can be certain of all username registrations.
• This message should be signed by us, and should include a statement in the text to the effect of "The username xyz has not yet been registered as of block #_____" only if that is true.
• Users should only trust username registrations signed by us.
• We can re-register all existing users.
• The app, when synced, should verify that the username registration was sent correctly.

Advantages:

1. We can still not censor username registrations once created, since the message we sent is permanent.
2. The user can register a username before they receive ZEC.
3. If a lightwalletd omits a username registration, a new spoofed username registration will not have our signature, and lightwallets won't accept it.
4. We can tell the user quickly if their username has been taken
5. We could trust this API instead of including user data in the app, but resync in the background.

We can also add some protections against our service misbehaving:

• If a zbay detects that we are spoofing transactions, it should lock up the UI and send proof of this to the username registration channel.
• If a zbay sees proof of spoofed transactions on username registration channel, it should verify and lock up the UI if confirmed.
• If a username wasn't registered correctly, the app can show an error and try again.
• We can connect via Tor so that we don't know the IP of the user

[holmesworcester]

Note: for old addresses we would start a new channel and re-register old addresses.

These should be broken up into separate tickets.

[holmesworcester]

Our best sense of how to mitigate this in the short term is by modifying zecwallet-light-cli to connect to multiple lightwalletd's and verify blocks.

[holmesworcester]

Created issues for lightwalletd and zecwallet-light-cli to address this.