Note that there are privacy weaknesses in Zcash’s current light wallet protocol that essentially let the servers figure out “who is paying who” among the users of the server. The wallet also reveals its transparent address to the server.
The servers are high-value targets for anyone wishing to de-anonymize shielded Zcash transactions or transparent addresses, so they should not be considered low risk. Even though all of the data stored on them is public information, the access patterns to that data are sensitive and need to be protected.
An ideal architecture for security should:
- Make it an easy and regular process to re-build the server instances from known-good state. This way if the instance is compromised, the compromise is short-lived because the instance will be rebuilt from a secure state after not too long. (e.g. use Docker)
- Prevent even the system administrators from accessing the production instances, e.g. it should not be possible for anyone to SSH into or run commands on the production instances once they have been started, or to obtain the TLS private key. If that’s necessary to do for debugging in emergencies, the SSH private key should be kept offline (in an air gap) until it’s needed and then rotated after use.
- Run on hardware that’s not shared with other tenants in a cloud environment, as a defence against cache side-channel attacks.
Security will become even more important if support for detection keys is added.