Scanner RPC Requirements

[teor2345]

Motivation

We want to provide secure access to the shielded blockchain scanner.

Goals

Based on the discussion in this week's Zebra team sync, we have the following goals for the RPC interface:

• Authenticates connections to make sure they are authorised to add or remove keys, or get results
• Encrypts connections to avoid leaking keys or results
• Requires proof of knowledge of keys before accessing results or deleting that key
• Can be used via Tor

Additional security requirement:

• The client should authenticate the server before sending private viewing keys.

Background & Security Notes

zcashd authentication

zcashd currently authenticates using either:

• proof of knowledge of the contents of a local cookie file, or
• username and password.

Passwords might be deprecated, we should ask the ECC team why that happened, and if they've made a final decision.

Tor compatibility

To be used via Tor, the RPC library must communicate over either:

• a PeerTransport: AsyncRead + AsyncWrite + ..., or
• arti::DataStream (or whatever the latest version of arti uses). See the linked examples for how this works in zebra-network.
• The library should also support TCP connections.

Tor onion addresses authenticate the server, but not the client. Tor did have client authentication in v2 onion services, but I'm not sure if it is implemented in v3. (v2 has been disabled.)

Authentication

Typically, proof of knowledge uses a challenge-response protocol, to avoid response re-use. A rough sketch of that protocol is:

• The server provides a random challenge value.
• The client responds with a hash of: a fixed prefix unique to this authentication method, the challenge value, and the secret (the password or the cookie file contents)
• The server checks that the hash matches the hash it generated from the challenge value and password

For proving knowledge of a key, we might just be able to use a prefixed hash of that key, because the connection is already authenticated and encrypted.

It's also possible to use client and server certificates, if we use TLS (or HTTPS).

Next Steps

• Scanner RPC Requirements #8153
  • Finalise the evaluation criteria for the RPC library
• Libraries for zebra-scan RPC Interface #8154
  • Make a list of potential RPC libraries and evaluate them against the requirements
  • Choose a library
• Create wrapper crate for using chosen library in Zebra
• Design and implement RPCs

[mpguerra]

Any other requirements that are not security requirements?

[mpguerra]

Some ideas for authenticating RPC connections were raised in #4575

[arya2]

Another consideration here could be ease-of-use, JSON is a bit easier to read during development.

[mpguerra]

@arya2 @upbqdn @oxarbitrage If there are no more requirements we can close this discussion as finished